Raspberry Pi How To: Resize SD card image

Copying the SD card contents to disk is easy done, but it takes up storage space of the same size as the memory card. Although it compresses down to a reasonable size once it is expanded the OS has to handle a rather large file. Resizing the image makes it much easier to handle.

For this process I use a virtual CentOS 6.5 machine running in Virtualbox with the image to be resized located in a shared folder.

Log into Terminal and become root with sudo su - and then follow the instructions below.

Gather information about the partitions located on the image in question.

parted -m /path/to/image unit B print


We are interested in the second line which describes the Raspberry Pi partition.
The first field represents the partition start at 62914560 bytes, we use that number in our next command:

losetup -f --show -o 62914560 /path/to/image

The output of losetup tells us teh naem of the loopback device to access this image is /dev/loop0. Next we need to perform a file system check on the device and fix any errors:

e2fsck -p -f /dev/loop0

If the above command reports an "unfixable" problem you should not continue any further until the problem is resolved.
Once you get the all clear from e2fsck proceed to resize the filesystem. First we find out the minimum filesystems size:

sudo resize2fs -P /dev/loop0

resize2fs 1.41.12 (17-May-2010)
Estimated minimum size of the filesystem: 598408

in the example above the minimum file size is 598408 block of 4kB each = 2 451 079 168 Bytes (about 2.4GB). We need to add a bit of spare space to this or our new file system will end up too small and that will cause write errors and followed by all manner of system difficulties. How much space you add is up to you but 100MB should be enough. 25000 blocks at 4kB = 102 400 000 Bytes.
598408 + 25000 = 623408 blocks

sudo resize2fs -p /dev/loop0 623408

The above command sometimes produces the message "Please run e2fsck -f /dev/loop0" - when I see this message I reboot the virtual machine, run "losetup -f --show -o 62914560 /path/to/image" and then the resize command shown above above works OK. Note: I do not run the e2fsck command.

resize2fs 1.41.12 (17-May-2010)
Resizing the filesystem on /dev/loop0 to 623408 (4k) blocks.
Begin pass 2 (max = 72544)
Begin pass 3 (max = 59)
Begin pass 4 (max = 6042)
The filesystem on /dev/loop0 is now 623408 blocks long.

Take note of the new file system length (623408) this number may could be larger than what you have asked for.

losetup -d /dev/loop0

The filesystem is now resized. Next we will adjust the partition size to match the new file system. This is achieved by removing the existing partition entry:

parted /path/to/image rm 2

We need to create a new partition entry which reflects our new file system size.
Use the byte number for the start of the partition which was established above since the start of the partition has not changed only the length has. Next we need to calculate the end of the new partition by converting the file system length to bytes and adding it to the start of the partition.
623408 Blocks x 4096 Bytes = 2 553 479 168 Bytes + 62914560 Bytes = 2 616 393 728 Bytes
Create the new partition with the following command:

parted -s /path/to/image unit B mkpart primary 62914560 2616393728

Check you new partition table

parted -m /path/to/image unit B print


The new partition entry size should now reflect your resized file system. the last step is to prune the unused part of the image file.
The total image size can be calculated by adding 1 to the bold number from the output above which represents the end of partition 2.
2 616 394 239 + 1 = 2 616 394 240

truncate -s 261639424vk0/path/to/image

The image file size is now reduced so one of the first steps after installing this image on an SD card should be to expand the filesystem to the size of the card.
This task is described in another article on this website.

Acknowledgement:  The information in this article was derived from a script developed by DeanC and posted in this forum.
I think Dean's calculation of the final size is wrong and makes the image larger than it needs to be. I have corrected this error in the article above.