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
  • Paste the output of a Linux command fdisk -l /dev/your_usb_key please. Mar 26, 2017 at 21:42
  • You could use the DISM tools on Windows to capture the data on the partition and shrink it to size. Or, another option is Ghost, that would work too. Mar 27, 2017 at 4:44
  • @ChefPharaoh interesting, but would the DISM tools work with Linux partitions too?
    – DARKGuy
    Mar 30, 2017 at 1:55
  • @DARKGuy I'd say it's worth a try. Just make a winpe usb stick and use the /compress maximum flag when capturing the partition. I'd be interested in knowing the result. Mar 30, 2017 at 3:39

1 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.

  • Alright, this makes sense because all says 512 bytes and you used that value as reference. While this could make sense (and why 4331520 if it's 4331519? +1 just because reasons?), I feel uneasy with this kind of calculations, isn't there an automatic way to do it? something like DD but strip the empty/non-partitioned space? how can I be so sure this would work without dumping it into a real drive for checking?
    – DARKGuy
    Mar 26, 2017 at 22:26
  • 1
    @DARKGuy I have expanded my answer. Mar 27, 2017 at 1:09
  • Okay, while it might not be exactly what I was looking for, it was a very detailed answer and it helped me to understand why it can't be done as easy as I want, so kudos for that, I learnt a lot from your post. Thanks! :D
    – DARKGuy
    Mar 30, 2017 at 1:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .