Assuming you are using Debian.
The Short Version:
Backup your system
Remove the main and swap partitions (leaving the boot partition alone)
Recreate the main partition to utilize the remaining disk space (excluding the boot partiton). Make sure to reuse the same start sector as the original root partition.
reboot the system
resize the new boot root ...
Using the Debian-Wheezy Beta image, there is a configuration utility built in that makes this easy:
There is a utility called raspi-config. This runs on first boot if you're connected directly to the RPi. If you're over SSH you can run it manually using $ sudo raspi-config. (I think you can re-run the tool manually at any time).
The second option on the ...
If you are not very comfortable working on the command line, like in Steve Robillards excellent answer, there are some GUI applications available. In particular gparted works very well.
I think it's installed by default on a Ubuntu LiveCD but not on an installed system. There is of course an easy fix for this: apt-get install gparted. You can't do this on ...
Alas no, it is not possible to connect a SATA device to the SD slot.
Unlike earlier flash memory standards like Compact Flash, which essentially used a Parallel ATA hard drive interface (scaled down in size) to attach flash memory, SD cards use a 1 or 4 bit serial interface and (more importantly) a different command protocol.
CF cards spoke the ATA command ...
Use the command ncdu. It is a console program to display disc usage. It has a ncurses GUI.
I usually run ncdu -x <some folder>, the x switch is there to not cross filesystem boundaries.
apt-get install ncdu
ncdu man page
See this link for a list of compatible cards:
The higher speeds are not necessarily a guarantee of performance. The problem observed at the moment is the support for the higher speeds required by the higher class SD cards, so there have been issues reported.
This is a driver issue, and hopefully it ...
After lots of reading and frustration. First of all, make sure the normal user has read and write acces to the USB drive. The correct 'non-root' fix for having write acces to the USB drive is:
Step 1: Stop transmission daemon
sudo service transmission-daemon stop
Step 2: Add pi to debian-transmission group
sudo usermod -a -G debian-transmission pi
Type n to create a new partition.
Type p to make a primary partition.
Next press enter when prompted for a partition number to choose the next available.
Press enter again to pick the next available sector to start the partition.
Press enter again to use all of the remaining disk space.
Type w to save the changes.
As explained in this question there are two methods of expanding the image. Below are two examples to expand the file by 1 kilobyte.
DD creates a non-sparse file
dd if=/dev/zero bs=1k count=1 >> myimage.img
Truncate creates a sparse file
truncate -s +1024 myimage
You probably want to use truncate. A sparse file only writes the metadata of the ...
Performance shouldn't decrease with larger cards (I'd say the same of your camera, perhaps it's more an issue with too many files/directories - some devices don't handle that well).
The Raspberry Pi supports SDHC cards, which can have capacities up to 32GB.
I'm no linux expert, but you could try this, might work.
Most of this is info came from
sudo service transmission-daemon stop
sudo nano /etc/init.d/transmission-daemon
# hit enter to overwrite
sudo service transmission-daemon start
I know running as root is a big linux ...
An incredibly easy way of resizing the image is to use one of the qemu tools called qemu-img. This of course depends on the fact that you have qemu installed (which I know you already do Alex).
The command looks like this:
qemu-img resize filename [+|-]size[K|M|G|T]
Where filename is the image file, and size is the size you want to enlarge (or shrink) the ...
You can boot from the SD card then just use an attached SSD, but you can not get around using the SD card for booting.
Once booted you can make the SD card read only and make sure all the software etc is running of the SSD
The Pi 2 should be able to run that HDD directly. However, by default the power to USB is limited to 600 mA, which is not enough (I've had the same issue with an external drive).
To make 1.2 A available -- which is fine if your power supply is up to it -- add the following to /boot/config.txt:
And reboot. Your HDD should now light up ...
As others have mentioned, df -h will give you overview. Also useful:
du -csh (show total disk space used in current tree)
du -csh /path (show total space used in specified tree)
du -csh (show space used in subdirectories)
You can also install the durep package which will give you a more granular breakdown of disk usage.
Linux kernel is caching disk operations. That means data is written not in real time, but when it is "time to do it".
There could be two reasons of behaviour you described:
1. Your SD card (or disk) is not fast enough to receive all the data you are producing.
2. Once in 30-40 seconds kernel is 'flushing' it's disk buffers, which unluckily freezes all disk ...
This will not really happen on the Pi unless one puts loads of stuff on there.
SD cards come in five maximum speed classes:
Class 1: maximum speed of minimum 1 MB/s
Class 2: maximum speed of minimum 2 MB/s
Class 4: maximum speed of minimum 4 MB/s
Class 8: maximum speed of minimum 8 MB/s
Class 10: maximum speed of minimum 10 MB/s
Above 10 MB/s there are ...
du -s * | sort -nr | head
-s prevents a lot of unnecessary output, -nr sorts numerically in reverse order and head cuts only the interesting part, you may omit it if you prefer all the results.
Also, if you need just an overview of your file system you may use
Filesystem 1K-blocks Used Available Use% Mounted on
I think it's unlikely that a Pi would work well, if at all, with FreeNAS.
Note the recommendation on their download page:
The new recommended boot device size is 8GB. FreeNAS 11 requires 8GB of RAM to run properly.
The Raspberry Pi 3 has 1GB of RAM. So that requirement seems to not be met, and it's not looking great so far for FreeNAS.
obarthelemy of ...
I believe your problem is your USB stick is formatted as NFTS or FAT, filesystems that do not support the per-user/group permissions. The solution is to reformat as ext4. If you do that, you will also have much less lag if you are using your Pi as a media center. The drivers for the Pi are much faster when you use ext4.
None of the answers here worked for me, so I am writing a new one referencing https://pimylifeup.com/raspberry-pi-torrentbox/ which worked great for me and allowed me to run transmission as pi user to access my USB drive. This is not directly answering the OP but this question is very popular (first Google result) for this sort of problem so I put it here.
I'm using a SanDisk Extreme Class 10 with UHS-U3 on my RPi3, I have the microSD driver overclocked and I hit 33.80MB/s while reading/writing.
Speed don't decrease with capacity, just ensure to use a good brand like SanDisk (Samsung had a hight corrupt % chances), If you need some speed, try to overclock your microSD card driver.
More info here
Already answered here dd-on-entire-disk-but-do-not-want-empty-portion
Assuming you want to save /dev/sdXN to /tgtfs/image.raw and you are root:
mkdir /srcfs && mount /dev/sdXN /srcfs
Use zerofill or just:
dd if=/dev/zero of=/srcfs/tmpzero.txt
To fill unused blocks with zero (wait for it to fill the file system completely then
This seems to be a classical unix rights problem. Let's have a look on it. To avoid confusion I set user of /media/NAS to root and then check where is the problem:
pi@raspberry ~$ sudo chown root /media/NAS
pi@raspberry ~$ mkdir /media/NAS/folder-pi # works
pi@raspberry ~$ su -l pi2 # login as pi2
pi2@raspberry ~$ mkdir /media/NAS/...