How to shrink/resize 32GB USB flash drive with 2GB partition into 2GB image file?

Question

I’ve been looking for info on how to shrink/resize—or directly dd—a 32GB USB flash drive I made for my Raspberry Pi into a 2G img file. I have resized the partitions, there’s one with Win32 FAT of 64M and the Linux partition is 2048Mb (2G), and all I want is just a dd IMG file of around 2G.

I know there is the Gzip compression method, but once uncompressed it will unpack a 32GB img file and sometimes I don’t have that much space. I just want to be able to dd the file into a 2GB USB flash drive, without having a 32G file with just 2G used in it. Get it?

Also, I’m using a SSD, and I’ve read that /dev/zero-ing the image file is kinda harmful, so I’m hoping there is an easier way to do it. I have Linux and Windows at my disposal, so I’m happy to hear suggestions!

Update: Unfortunately I made a mistake and replaced the USB flash drive with another drive, but I have the whole img file I just mounted to /dev/loop0 and ran fdisk -l to it, here’s the output:

Disk flashrom32g.img: 29.8 GiB, 32010928128 bytes, 62521344 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xaebebc78

Device           Boot  Start     End Sectors Size Id Type
flashrom32g.img1        8192  137215  129024  63M  c W95 FAT32 (LBA)
flashrom32g.img2      137216 4331519 4194304   2G 83 Linux

Answer 1

The relevant part of your USB key takes exactly 4331520 sectors of 512 bytes (numbered from 0 to 4331519), so the command should be:

dd if=/dev/your_usb_key of=/path/to/image.dd bs=512 count=4331520

---

Edit (to address the comment):

and why 4331520 if it's 4331519? +1 just because reasons?

If sectors were numbered from 1 and the last one was the 4331519th then there would be a total 4331519 of them. But as I said they are numbered from 0, that's why count=4331520.

I feel uneasy with this kind of calculations, isn't there an automatic way to do it?

Frankly I don't know. I tend to think if you need to do such tricks then you should better understand what you're doing. And if you understand then you can do the math and you know the pitfalls, and you feel uneasy without your own calculations.

something like DD but strip the empty/non-partitioned space?

You don't want to strip all the non-partitioned space. There is MBR with partition table in sector 0. Your sectors 1..8191 may contain bootloader code.

If there was GPT, there would be a backup partition table at the very end of the disk and it would be in non-partitioned space also.

Moreover if your partitions had space between them, then your dd-like tool just couldn't skip it because it would effectively shift the latter partition towards the beginning of the image and the partition table (in the image) would have to be adjusted. Another strategy in this case would be to replace this mid-partition space with zeros on the fly while writing the output image as a sparse file.

One more pitfall: read this question and my answer there, then think how sophisticated the tool needs to be to successfully strip the non-partitioned space from this mess.

In general you can always make separate images of MBR (or MBR + bootloader) and every single partition. In your case it would be something like this:

dd if=/dev/your_usb_key of=/path/to/image_MBR_bootloader.dd bs=512 count=8192
dd if=/dev/your_usb_key1 of=/path/to/partition1.dd
dd if=/dev/your_usb_key2 of=/path/to/partition2.dd

If you want to strip the empty space (i.e. the space shown by df) then you should use a tool that understands the filesystem and works on files level, not disk sectors. I'm sure dd (or something like dd) is not the right tool for this kind of job.

how can I be so sure this would work without dumping it into a real drive for checking?

Learn, so one day you can say "I know what I'm doing". Trials and errors are parts of learning process. I suppose dumping the image into a real drive for checking would be a good trial.