Ebrius Disputatios

When the image file is made, it is going to use the entire drive to create one large image the size of the entire disk regardless of free or used space. In this tutorial, I hope to give insights on how to resize the image safely, using disk utilities and file system tools. In this example the gparted utility will be used.

If we want to modify partitions and file systems in our disk image file, we will need to mount the image as a so-called loop device in Linux. Not only will we need to mount the image as a loop device, but we also need to make sure that our loop device will auto create additional device entries for the partitions detected on our image. On Ubuntu, this function is baked into the Linux kernel, and this functionality can be enabled in the following way:

• edit /etc/default/grub

Add the following:

• maxloop=64 As last parameter on the following line: GRUBCMDLINELINUXDEFAULT=“” * Now execute to activate: with update-grub2 * Now reboot your station and verify if the loop devices are available with: ls /dev/loop* * sudo losetup -Pf mypinephone.img

Of course this is all predicated on the fact that one, does, in fact, have grub on one's system. I one doesn't, this step can be bypassed. For instance, Raspberry Pi's don't usually have grub and neither do many ARM based systems. So as I said, this step is not necessary in those circumstances.

You can list the partition table of an image file with the following command:

• fdisk -l mypinephone.img * It should look something like this:

Device Boot Start End Sectors Size Id Type

/dev/mmcblk2p1 * 16384 1048575 1032192 504M 83 Linux

/dev/mmcblk2p2 1048576 61071326 60022751 28.6G 83 Linux

We gather from the partition table that we have two available partitions in the image file. Before we can make any modification to the partitions or filesystems in our image, we will first need to mount the image as a loop device, which will install the required dev entries to address our partitions with other software as gparted.

To mount the image as a loop device:

The above step, works really well for Debian based systems. For other systems, if the above command does not work, then use this one:

• sudo losetup —find —show mypinephone.img

This will mount /dev/loop0 as a ‘virtual raw disk’ and it’s containing partitions accordingly as /dev/loop0p1 and /dev/loop0p2

Now that we have set-up our raw imagefile as a loop device, we can run filesystem tools on it. We can use for example gparted to resize the file systems contained in the partitions of our image:

• gparted /dev/loop0

Do any resize operation that you would like to have for your partitions and apply them, in my case I needed to trim down my image size as small as possible. Now that the resize operations have been done in our raw disk image, we will dump the partitions to a smaller image. First, before we remove our loop device, for the image, as it will interfere with the dump process, take these steps:

• sudo fdisk /dev/loop0 * It should look something like this:

Device Boot Start End Sectors Size Id Type

mypinephone.img1 * 16384 1048575 1032192 504M 83 Linux

mypinephone.img2 1048576 15298559 14249984 6.8G 83 Linux

The key figure to note is the ending value of the second partition, in this case /dev/mypinphone.img2, which turns out to be 15298559, thats going to be our key to having a viable image to flash to our pine phone. Now our original image, created by dd was 30GB the size of our entire SD card, that just wont do. So now with the aid of gparted we've just shrunk our image from 30GB to around 7GB. Now this is an image of our pine phone with all our latest modifications and improvements and we do not want to have to start over. Flashing this image will actually put us right where we were, and right where we belong. Now that we have our number of blocks to dump, ie 15298559, we can safely, unmount our loop devices, by doing this:

• sudo losetup -d /dev/loop0

Now list our partition table so we have an idea what to dump:

In our partition table we can see that our blocks are 512 bytes long, and we have a total number of 15298559 blocks to dump … doing the actual dump is done with dd which just reads raw blocks of data and dumps them somewhere.

• dd bs=512 count=15298559 if=my-big-pinephone.img of=my-resized-pinephone.img

• bs = the block size to read

• count = the amount of blocks to dump

• if = input file to read from

• of = output file to write to

It's a little scary and intimidating the first time that you read this but you may want to do some safe practice exercises and think about what needs to be done. However, once you read, and re-read this document it will become clearer and you'll find your way. I'd like to acknowledge the original progenitor of this method by linking to his post. Thanks to all of you.

Many concepts for this post, was copied from this article written by Ronny Van den Broeck. Thanks Ronny.