I installed Raspbian to a 16 GB card and expanded the filesystem. When I made a dd backup of the card, the .img file output was ~16 GB. Most of it is unused space in the ext4 partitionI'm only using like 2.5 GB in that partition. (There are two partitionsthe first is FAT for boot and the second is ext4 for rootfs.) I'd like to shrink the backup.img file which resides on an Ubuntu 16.04 Sever installation (no GUI) so that I can restore the image to a card of smaller size (say 8GB for example).So far, I have mounted the ext4 partition to /dev/loop0 by using the offset value provided to me by fdisk -l backup.img. Then I used e2fsck -f /dev/loop0 and then resize2fs -M /dev/loop0 which appeared to shrink the ext4 fs... am I on the right track? I feel like parted might be next, but I have no experience with it.How do I accomplish this using only cli tools?Update:Here is the output from running fdisk -l backup.img:Disk backup.img: 14.9 GiB, 15931539456 bytes, 31116288 sectorsUnits: sectors of 1 * 512 = 512 bytesSector size (logical/physical): 512 bytes / 512 bytesI/O size (minimum/optimal): 512 bytes / 512 bytesDisklabel type: dosDisk identifier: 0x79d38e92Device        Boot  Start      End  Sectors  Size Id Typebackup.img1 *      8192   124927   116736   57M  e W95 FAT16 (LBA)backup.img2      124928 31116287 30991360 14.8G 83 Linux
Shrinking Raspberry Pi SD .img via Ubuntu Server (cli)
debian;command line;disk image
I can confirm you are in the right track shrinking that filesystem; fdisk/parted is next. The tricky part is getting it right next to the size of the new filesystem,do your math or leak a hundred KB more just to be safe. You can adjust it later on the new card if need be.The order is normally: umount, resize, fdisk/parted, partprobe, fsck, and mount to check all is ok. As the partition you are resizing is less than 2T, you can use either fdisk or parted.The resize process has to come first, as you wont be able to shrink the partition reliably while the filesystem still claims the space you need to reclaim. After you need to shrink the partition once again for consistency, and for not having the remaining space you want to rid off booked for use. The filesystem as to come last to make the filesystem structure consistent with the new size.I will leave these RH articles. It is missing the partprobe, as the new partition size is not always recognised immediately or by older kernels.How to Shrink an ext2/3/4 File system with resize2fsHow to Resize a Partition using fdiskYour missing steps are:sudo fdisk /dev/loopp     - to check for partition number (probably 2)d     - to delete2     - partition 2n     - new partitionp     - primaryENTER - default beginning+new size -  smaller card sizew      - write itsudo partprobe /dev/loopTo finish it off, you umount the image file; as the extra size is no longer marked as used both by the filesystem and the partition size in your file image, the operation system wont try to use that space. So it can be  truncated safely to the intended size:truncate -s 8GB fileNameTo use the appropriate sizes, as I am lazy, I would shring the filesystem to something less than what I need (i.e. size of new partition - 400k, and then expand it again after I shrink the partition), and would create the partition with the needed size (8GB-2048(2K) for possible 1st partition padding-minus the size of the 1st partition). Not much math involved. For calculating it properly, please do have a look:How To Resize ext3 Partitions Without Losing Data