clone ssd boot disk

How did you copy the partitions?

you've not given a lot of information.

For instance what was your cmdline.txt file and what is it now?

Are you sure the new /boot partition is in VFAT format?

I use "rip-clone" which creates a bootable backup of the current boot disk. Size differences don't matter as long as te target disk is big enough to hold the whole contents of your current boot disk.

Also, I found it to be good practice to format the target disk. If you don't then you're backup may or may not boot.

I used rsync to copy everything (hopefully) by using another computer running linux, and both disks connected to the computer through USB3.

Yes, two partitions. FAT32 for boot and ext4 for root.

cmdline.txt in 128G disk (current running) is as below:

console=serial0,115200 console=tty1 root=PARTUUID=7295e545-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

And I've changed root=PARTUUID=7295e545-02 to the 120G disk partuuid, which I have manually changed to 7295e546-02 by fdisk.

From my understanding, files in boot partition are not required in particular sectors of hard drive and there is no such thing like MBR.

Having read some information about the boot sequence of the Raspberry Pi from website

1. Stage 1 boot is in the on-chip ROM. Loads Stage 2 in the L2 cache
2. Stage 2 is bootcode.bin. Enables SDRAM and loads Stage 3
3. Stage 3 is loader.bin. It knows about the .elf format and loads start.elf
4. start.elf loads kernel.img. It then also reads config.txt, cmdline.txt and bcm2835.dtb If the dtb file exists, it is loaded at

1. kernel.img is then run on the ARM.

At stage 4, system will read config.txt and cmdline.txt. I believe there is no partition information in config.txt, and only cmdline.txt is required to change in boot partition for the partuuid.

I suppose rsync is not suitable for this?

Hi Paul,

Thanks for the information. I haven't heard of this software before, and I'll have a try during Xmas break.

No need for anything fancy here. I've been using the built-in SD Card Copier to backup my SSD to a flash Drive. The software doesn't care that there's no SD card in the mix. Oh, and by the way, My pi 4 boots and runs just fine from the flash drive, just a bit slower, due to the nature of the media.

at> As the 120G ssd is not the same size and brand as the 128G one, I at> couldn't use dd to clone whole disk. Then I did it manually by copying at> boot partion and root partion to the 120G disk partitions seperately. at> I've also changed the disk identifier in /etc/fstab and cmdline.txt to at> match the 120G disk, but it won't boot.

Why wouldn't a standard 'dd if=/src of=/destination' work? So long as the /destination is LARGER than the /src, it should write [clone] with no issues.

|07p|15AULIE|1142|07o |08.........

It should be. I use the options -vauxXAH

what does sudfo blkid say for the new disk?

Have you got a monitor connected or a serial console connection? Do you get any output?

It's not a special piece of software. It's just a shell script that does everything for you that needs to be done. All the tools the shell script uses are already part of your Linux distribution.

Cheers, Paul

This is how I image storage devices for the Raspberry Pi. I use it with MicroSD cards, but I see no reason why it wouldn't work with other types of storage.

Even then, assuming there's space on the 128 GB card, he could've just resized the file system(s) so they take at most 120 GB and dded away. Seems weird the OP didn't just do that.

You also seem to miss OP's first sentence :

"My respberry pi 4 is currently booting from a 128G ssd disk thourgh usb and everything is fine. I just got a spare 120G ssd disk ..."

That is the new disk is smaller. The destination is not larger - it is SMALLER

The image file of the disk can be shrunk on another Linux computer by setting up a loop drive with partitions:

sudo losetup -f -P --show path_to_image_file

You can then start gparted with the listed /dev/loop as an argument:

sudo gparted /dev/loopn

replacing /dev/loopn with the reported device, e.g. /dev/loop3

Gparted can be used to shrink the ext4 partition to the size really used (leaving a few megabytes to spare). After the shrink check from the information menu the last sector of the ext4 partition, add one and divide by 2048 to get the new image size in megabytes.

Remember to disconnect the loop device before adjusting the image file:

sudo losetup -d /dev/loopn

The image file can then be truncated with the truncate command:

truncate -s new_file_size path_to_image_file

Please note that a recent Linux distributions use a bunch of loop devices, so to be safe, it is a good idea to let losetup to find the loop device. My Kubuntu 2204 LTS uses 10 loop devices for itself.

The copied disk can be expanded to fill the available space with raspi-config:

sudo raspi-config

Select 6 Advanced Options, then A1 Expand Filesystem, and follow the on-screen instructions, reboot when instructed so.

HTH

I made a comment earlier in this thread, but it may have been lost in the shuffle, perhaps due to me omitting a few key details. I boot and run my pi 4 from a 256 GB SSD, but at this time the drive is extremely under-utilized. I use SD Card Copier to backup this drive to a much, much smaller capacity flash drive. SD Card Copier doesn't care what size the destination drive is, as long as all the source data will fit.

As I said before, my backup flash drive boots and runs just fine.

Depending on the original poster's unique situation, it may be quite possible to backup a 128 GB SSD to to a 120 GB SSD using SD Card Copier.

Dana Sun, 4 Dec 2022 18:23:04 +0000, attend snipped-for-privacy@homesrv.net napis'o:

I would use resize2fs to shrink the last partition on the source to make data under 120G. You should boot from SD card to do this. Than boot from source drive to confirm that everything is ok... Than boot from SD... Than copy the whole source drive to destination drive.

I do following trick

given /dev/sda1 is boot and /dev/sda2 is root of the source drive and /dev/sdb1 is boot and /dev/sdb2 is root of the target drive I mount /dev/sda2 on /mnt/source and /dev/sda1 /mnt/source/boot then I mount /dev/sdb2 on /mnt/target and /dev/sdb1 /mnt/target/boot

so now cd /mnt/source && tar cf - . | (cd /mnt/target; tar xvf -)

tar would preserve groups and permission. However this would not boot if UUIDs are used. One should modify /etc/fstab in /mnt/target and update initram if used

If you want identical UUIDs, then dd only the partition table and use the method above to transfer the content (after formatting)

The cool thing with tar is, you can use it over SSH

tar cf - . | ssh myhost 'cd /media/myuser/mydisk && tar xvf -' (see Unix Power Tools, 3rd Edition. ch10.13)

BR

That is fine for small amounts of data but is terribly inefficient for entire discs with GB of data.

rsync is a much better tool for the job, and had the advantage that should the copying be interrupted for any reason, just issuing the command again will cause it to continue from exactly where it went off.

rsync with -axHAXP flags will preserve all attributes including hard links, and show the progress. It's even possible to copy a live system this way (such as when doing incremental backups) but you need to specify a number of directories to exclude for that, so you don't copy things such as /dev or /proc

---druck

You need not to have any active databases or similar cached stores operating at the time also any files being written at the time of the copy will be corrupt or at least truncated.