Clone Larger SDcard on Smaller

My problem is same as here Sandisk 64GB sdcards but newer one is ~25mb smaller

Untested

This method I didn't test

Failed attempts

• Using windows application like Paragon Hardisk Manager, MiniTools & EaseUS didn't work. Cloning disk in each application resulted in an error even after some time
• rpi-clone didn't work, issue raised
• pishrink method seems convenient but didn't work

wget https://raw.githubusercontent.com/Drewsif/PiShrink/master/pishrink.sh
chmod +x pishrink.sh
sudo ./pishrink.sh ~/Desktop/Disk\ Image\ of\ mmcblk1\ \(2025-08-08\ 2028\).img  ~/Desktop/compressed.img
[sudo] password for ukhan: 
PiShrink v24.10.23 - https://github.com/Drewsif/PiShrink

pishrink.sh: Copying /home/ukhan/Desktop/Disk Image of mmcblk1 (2025-08-08 2028).img to compressed.img...
pishrink.sh: Gathering data
Creating new /etc/rc.local
pishrink.sh: Checking filesystem
armbi_root: 334941/3829920 files (0.3% non-contiguous), 7819298/15527680 blocks
resize2fs 1.46.5 (30-Dec-2021)
pishrink.sh: Shrinking filesystem
resize2fs 1.46.5 (30-Dec-2021)
Resizing the filesystem on /dev/loop1 to 7978317 (4k) blocks.
Begin pass 2 (max = 1053422)
Relocating blocks             XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 3 (max = 474)
Scanning inode table          XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 4 (max = 46548)
Updating inode references     XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
The filesystem on /dev/loop1 is now 7978317 (4k) blocks long.

pishrink.sh: Zeroing any free space left
pishrink.sh: Zeroed 1.1G
pishrink.sh: Shrinking partition
pishrink.sh: Truncating image
pishrink.sh: Shrunk compressed.img from 60G to 31G

The resulting image when tested with fdisk didn't have any partitions rather a single continuous partition with no name & format

• Using gparted resized ext4 / mount point to just +2GB over used data.

ukhan@orangepi4a:~/Downloads$ fdisk -l /dev/sdb # target device 
Disk /dev/sdb: 59.48 GiB, 63864569856 bytes, 124735488 sectors
Disk model: SD Card Reader  
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: 0xd9749913

Device     Boot Start       End   Sectors  Size Id Type
/dev/sdb1        2048 124735487 124733440 59.5G 83 Linux

ukhan@orangepi4a:~/Downloads$ fdisk -l /dev/mmcblk1  # source after resizing
Disk /dev/mmcblk1: 59.5 GiB, 63887638528 bytes, 124780544 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: gpt
Disk identifier: 7D013D90-9C88-CC4A-BC9A-EF3DC2DF66CF

Device          Start      End  Sectors  Size Type
/dev/mmcblk1p1  32768   557055   524288  256M Linux extended boot
/dev/mmcblk1p2 557056 69625855 69068800 32.9G Linux root (ARM-64)

Then trying this cat /dev/mmcblk1 >/dev/sdb No root required. Make sure no partition is mounted using lsblk This failed

cat: write error: No space left on device Thus we have to do partition by partition...

Using gdisk /dev/mmcblk1 backup source partition table to a file ukhan.bck You have to type ? to get general help then typing b will back up GPT data to a file You can name file anything it will be located in /home Using gdisk /dev/sdb we have to write source's partition table to target device because we are sure that partitions will now fit on target. Type r to enter Recovery/transformation & then type l for load partition data from a backup file then type filename & finally type w to save changes Launch sudo gparted & you can visually see that besides unused space at end all partitions are same size & format. Now do partition by partition mirroring. Check lsblk to ensure correct syntax of following

cat /dev/mmcblk1p1 >/dev/sdb1
cat /dev/mmcblk1p2 >/dev/sdb2

After process in done relaunched gparted > Partition > Information The UUID seems to be identical between source / target. At launch it will notify you that /dev/sdb partiton can be resized. We will resize / partition by dragging slider to right (use all available space), however, skip 1MB at the end (it should remain unallocated) The whole process didnt produce any error but Radxa3E failed to boot from new sdcard while it still booted from old sdcard (with resized partitions)

Successful Method

• This method is being followed. Create a complete uncompressed image dd if=/dev/<source> of=/home/Desktop/<name>.img. Mount it losetup --find --partscan ukhan.img Now lsblk will indicate virtual partitions being mounted as device /dev/loopX Modify image sudo gparted /dev/loop0shrink (resize) ext4 / mount point to just +2GB over used data. At the end of device unallocated space will increase. After operations are done close gparted & unmount image sudo losetup -d /dev/loop0 Check contents inside image

fdisk -l ~/Desktop/mmcblk1-2025-08-082028.img 
Disk /home/ukhan/Desktop/mmcblk1-2025-08-082028.img: 59.5 GiB, 63887638528 bytes, 124780544 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: gpt
Disk identifier: 7D013D90-9C88-CC4A-BC9A-EF3DC2DF66CF

Device                                           Start      End  Sectors  Size Type
/home/ukhan/Desktop/mmcblk1-2025-08-082028.img1  32768   557055   524288  256M Linux extended boot
/home/ukhan/Desktop/mmcblk1-2025-08-082028.img2 557056 73103359 72546304 34.6G Linux root (ARM-64)

Truncate the image using these instructions

The selected answer applies perfectly for DOS disklabel type. For GPT type, one needs to consider adding 33 sectors as GPT stores a table also at the end of the disk. So for GPT users, 'truncate' commands needs to look like this: truncate --size=$[(End_of_last_partition+1+33)*512] myimage.img

I got these errors

Caution: The CRC for the backup partition table is invalid. This table may
be corrupt. This program will automatically create a new backup partition
table when you save your partitions.

Problem: The secondary header's self-pointer indicates that it doesn't reside
at the end of the disk. If you've added a disk to a RAID array, use the 'e'
option on the experts' menu to adjust the secondary header's and partition
table's locations.

Problem: Disk is too small to hold all the data!
(Disk size is 73103393 sectors, needs to be 124780544 sectors.)
The 'e' option on the experts' menu may fix this problem.

Warning: There is a gap between the main partition table (ending sector 33)
and the first usable sector (2048). This is helpful in some exotic configurations,
but is unusual. The util-linux fdisk program often creates disks like this.
Using 'j' on the experts' menu can adjust this gap.

Problem: GPT claims the disk is larger than it is! (Claimed last usable
sector is 124780510, but backup header is at
124780543 and disk size is 73103393 sectors.
The 'e' option on the experts' menu will probably fix this problem

Partition(s) in the protective MBR are too big for the disk! Creating a
fresh protective or hybrid MBR is recommended.

After relocating partition table by typing e in expert menu & typing w this error happens

Warning! Secondary partition table overlaps the last partition by
2014 blocks!
Try reducing the partition table size by 8056 entries.
(Use the 's' item on the experts' menu.)
Aborting write of new partition table.

While in expert menu type s & reduce partition table size I used 50 (have to be between 4 & 128) It gave me warning but I finalised actions by typing w Now fdisk ~~/Desktop/mmcblk1-2025-08-082028.img properly showed partitions in image & gdisk reported no error gnome-disk-utility was used to burn .img to target Use gparted to again resize the partition to use unallocated space (left ~3mb at the end) as explained here

SUCCESS RADXA booted!

#linux #data