0

I have built a custom image of Armbian with a partition size of 3.1 GB, and I am now finished working with it. It is currently written to a bootable 64 GB SD card which is using a GUID partition table (GPT).

My problem is, is that when I want to make an image of the card using Ubuntu, I get an image file 63 GB in size, but I don't want an image file with 60 GB of empty space.

I looked for other ways of shortening the image file by using truncate command, and creating an image using dd count= and it isn't working. When I use dd it creates an image file that when mounted is all "free space" and PMBR, and truncate breaks a working image file.

So (unless I'm doing it wrong), how can I create a 3 GB image of my SD card that will contain the boot information?

  • What is your goal? If you simply want to store it compactly for later reuse, you can simply zip it to make it even smaller than 3 GB and later do gunzip -c image.gz |dd of=/dev/sdx (adapt to your card's device file) – Philippos May 27 '22 at 07:43
  • Hi @Philippos, my goal is to create an img file of the SD card containing the armbian partition and boot info from the SD card, without the extra 60gb of free space so that when i come to write it to an SD card, i only write 3gb, not 64gb – Chris Hudlin May 27 '22 at 07:49

1 Answers1

0

truncate is a good tool. You need to shrink the image, so it contains every partition defined in the partition table. In other words, if the end sector of the partition closest to the end is N (note it doesn't have to be the partition with the highest number), you need N+1 sectors of the image (+1 because numbering starts at 0).

Use gdisk -l image to know the N.

Most likely the card uses 512-byte sectors and the partition table is valid when interpreted in terms of 512-byte sectors (for comparison: see what happens when this assumption does not hold). So you need (N+1)*512 bytes (or more, having more is not fatal). truncate accordingly.

Reading this number of bytes directly from the card in the first place would give you the same result. An easy way (although non-POSIX, see this) is head -c number-of-bytes-here /dev/sdx > image.

Then you need 33 additional logical sectors for a secondary (backup) GPT. Use truncate again and add 33*512 bytes to the file (truncate -s +16896 image). We could have shrunk the image to the desired final size with the first truncate (or read more with head), but doing this in two steps causes these additional 33 sectors to contain zeros instead of garbage that might interfere in a moment.

The first truncating (or creating a partial image) discarded the original secondary GPT. Use gdisk image and let it fix the problem. It will tell you that disk size is smaller than the main header indicates and invalid backup GPT header, but valid main header; regenerating backup header from main header. Thanks to the second truncate there is room for the backup GPT. All you need is to "write table to disk and exit"; the tool will rewrite GPT, including the backup one.