Cloning and trimming a RaspberryPi microSD card

Posted 05-05-2024 at 09:30 PM by rouvas

A mini how-to on cloning (i.e. making an exact copy) and trimming (i.e. not copying any empty space at the end of the useful stuf) a RaspberryPi microSD card. The procedure should be applicable to other images as well, but I'm only reporting what I've tried.

Now if the source SD card can be accessed all of it is a lot more easier if the steps outlined at https://forums.raspberrypi.com//view...88670#p1745960 are followed.

However if you're like me who made an image of the original SD card and then discarded only to find out that the target SD card was a tad smaller than the original then keep on reading.

First things first, starting with copying the original SD card. With trusty "dd" that step is easily done.

Code:

dd if=/dev/mmcblk0 of=sd.img bs=4M

Please find out the device where the source SD card is inserted with "fdisk -l" and/or "lsblk" before running the "dd" command so that you don't end up copying the wrong image.

Inspecting the resulting "sd.img" with "fdisk -l sd.img" would result in something like:

Code:

# fdisk -l sd.img
Disk sd.img: 29.45 GiB, 31624003584 bytes, 61765632 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: 0x97709164

Device     Boot  Start      End  Sectors  Size Id Type
sd.img1           8192   532479   524288  256M  c W95 FAT32 (LBA)
sd.img2         532480 61765631 61233152 29.2G 83 Linux

This is all fine and well, but there is no indication of any unused space at the end of the second partition "sd.img2" and I was certain I was using considerable less space than the 29.2G reported.

I needed a way to find out where the useful stuff ended and where the empty space begun. Whilst fiddling around the interwebs I came about this gist:https://gist.github.com/dkebler/92aa...b6b07c7abe12b4 which looked quite promising.

Executing

Code:

# ./rock64shrink.sh -t -v sd.img sd2.img

Gave me some errors about the first partition, a DOS one, which I promptly ignored.

Examining the resulting "sd2.img" image with "fdisk -l" revealed the following:

Code:

# fdisk -l sd2.img.img 
Disk sd2.img.img: 29.45 GiB, 31624003584 bytes, 61765632 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: 0x97709164

Device       Boot  Start      End  Sectors  Size Id Type
sd2.img.img1        8192   532479   524288  256M  c W95 FAT32 (LBA)
sd2.img.img2      532480 18518968 17986489  8.6G 83 Linux

which looked like what I was after. 8.6G looked just about right for the amount of spaced I've used in the source SD. Furthermore, mounting the "sd2.img.img" ( with "mount sd2.img.img /mnt" , for example) did not reveal any errors. I was still reluctant to use the "sd2.img.img" for imaging a new SD card due to the aforementioned errors so I went with the original "sd.img". After some calculations I ended up using "9209082880" as the number of bytes that should be copied ("( 17986489 + 1 )* 512 = 9209082880").

All that was left was to copy this amount of bytes from the "sd.img" image to a new SD card. Again trusty "dd" to the rescue

Code:

dd if=sd2.img.img of=/dev/mmcblk0 count=9209082880 status=progress iflag=count_bytes bs=4M

That's it! Job done!

I was now holding a new SD card being an exact copy of the original.

Final note: Please take care making sure your input ("if") and output ("of") devices when using "dd". Especially with the output one. "dd" will happily overwrite it, so do use "fsisk" and "lsblk" to find out the proper target.

Cloning and trimming a RaspberryPi microSD card

Comments