framps
commented
4 days ago Looks like it's a duplicate of https://github.com/geerlingguy/rpi-clone/issues/31.
Closed SeimusS closed 3 days ago
framps
commented
4 days ago Looks like it's a duplicate of https://github.com/geerlingguy/rpi-clone/issues/31.
fmarzocca
commented
4 days ago Looks like it's a duplicate of #31.
Yes, I agree! Disable automount a re-generate a full clone with -f switch.
SeimusS
commented
4 days ago Thank you both for quick responces!
I will try it out and report back (PS sorry I missed that #31 totally my fault)
Regards, S.
SeimusS
commented
4 days ago So, after disabling usbmount the rsync doesnt throw any more errors. Yet I am still not able to boot from the disk. The moment I remove the SD RPI4 wont boot with the disk only.
What I am doing wrong?
$ sudo rpi-clone -f sda
Booted disk: mmcblk0 62.4GB Destination disk: sda 250.1GB
---------------------------------------------------------------------------
Part Size FS Label Part Size FS Label
1 /boot 256.0M fat16 -- 1 256.0M fat16 --
2 root 57.9G ext4 retropie 2 232.6G ext4 --
---------------------------------------------------------------------------
== Initialize: IMAGE partition table - forced by option ==
1 /boot (48.5M used) : MKFS SYNC to sda1
2 root (12.6G used) : RESIZE MKFS SYNC to sda2
---------------------------------------------------------------------------
Run setup script : no.
Verbose mode : no.
-----------------------:
** WARNING ** : All destination disk sda data will be overwritten!
-----------------------:
Initialize and clone to the destination disk sda? (yes/no): yes
Optional destination ext type file system label (16 chars max):
Initializing
Imaging past partition 1 start.
=> dd if=/dev/mmcblk0 of=/dev/sda bs=1M count=8 ...
Resizing destination disk last partition ...
Resize success.
Changing destination Disk ID ...
=> mkfs -t vfat /dev/sda1 ...
=> mkfs -t ext4 /dev/sda2 ...
Syncing file systems (can take a long time)
Syncing mounted partitions:
Mounting /dev/sda2 on /mnt/clone
=> rsync // /mnt/clone with-root-excludes ...
Mounting /dev/sda1 on /mnt/clone/boot
=> rsync /boot/ /mnt/clone/boot ...
Editing /mnt/clone/etc/fstab PARTUUID to use b1d73664
===============================
Done with clone to /dev/sda
Start - 20:20:05 End - 20:29:07 Elapsed Time - 9:02
Cloned partitions are mounted on /mnt/clone for inspection or customizing.
Hit Enter when ready to unmount the /dev/sda partitions ...
unmounting /mnt/clone/boot
unmounting /mnt/clone
===============================Regards, S.
framps
commented
4 days ago For some unknown reasons the UUID in /boot/firmware/cmdline.txt is not updated :thinking:
You can fix this with syncUUIDs as a workaround.
As far as I understand in #31 it's not usbmount which is used.
Another workaround seems to be to set /boot back to RW instead of RO. Frankly I don't understand why this option is offered in raspi-config. /boot is just read during boot all the time and will not harm any SD card.
SeimusS
commented
4 days ago @framps thanks for the suggestion. I will try this again I did remove usbmount completely from the system and installed udevil/devmon. Because when I had ubmount, after stopping it the rpi-clone looked that went fine. But after rebooting I had even problems to auto mount the drive...
I will try this first, cause this is just insane.
Regards, S.
SeimusS
commented
4 days ago Sadly the same results.
I stop automount, run rpi-clone -f sda, it goes thru "fine", remove the SD device wont boot...........
@framps Do you known what should be in /etc/fstab after rpi-clone -f is run? Should it reflect the new PARTUUID of the SSD disk?
Disk /dev/mmcblk0: 58.1 GiB, 62411243520 bytes, 121896960 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: 0x005bdc9a
Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 * 8192 532479 524288 256M e W95 FAT16 (LBA)
/dev/mmcblk0p2 532480 121895007 121362528 57.9G 83 Linux
Disk /dev/sda: 232.9 GiB, 250059350016 bytes, 488397168 sectors
Disk model: Forty
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: 0x4c0ec3fc
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 8192 532479 524288 256M e W95 FAT16 (LBA)
/dev/sda2 532480 488397167 487864688 232.6G 83 Linux
proc /proc proc defaults 0 0
PARTUUID=005bdc9a-01 /boot vfat defaults 0 2
PARTUUID=005bdc9a-02 / ext4 defaults,noatime 0 1
# a swapfile is not a swap partition, no line here
# use dphys-swapfile swap[on|off] for thatRegards, S.
framps
commented
3 days ago Should it reflect the new PARTUUID of the SSD disk?
Yes. But according the messages the fstab is updated. But cmdline.txt is not updated - for any unknown reasons.
You can use syncUUIDs to check and fix any UUID mismatches.
SeimusS
commented
3 days ago @framps I and trying to run the script but its not working. I don't know if I got stupid or what...
~/raspberryTools $ sudo ./syncUUIDs.sh /dev/sda
syncUUIDs.sh 0.1.1 (https://github.com/framps/raspberryTools)
./syncUUIDs.sh: line 88: 2: unbound variable
??? ASSERTION FAILED: Unable to collect required data
I checked the code and the error message doesn't make sense there.
Please execute
script syncUUIDs
sudo bash -x syncUUIDs /dev/<yourDev>
exitand attach the file syncUUIDs here and I can check what's going wrong.
SeimusS
commented
3 days ago Here you go
~/raspberryTools $ cat syncUUIDs
Script started on 2024-07-03 23:45:50+02:00 [TERM="xterm-256color" TTY="/dev/pts/0" COLUMNS="206" LINES="74"]
root@CZ-HRUS-RPi-DNS01:/home/pi/raspberryTools# sudo bash -x syncUUIDs /dev/sda
root@CZ-HRUS-RPi-DNS01:/home/pi/raspberryTools# exit
exit
Script done on 2024-07-03 23:46:13+02:00 [COMMAND_EXIT_CODE="0"]
:cry: I expected a huge file.
If you want to help to debug this issue head over to my repo.
So now you have to manually update the UUID in /boot/firemware/cmdline.txt
1) Retrieve the UUDI with sudo blkid
2) Mount /boot
3) Edit /boot/cmdline.txt and change the UUID to the UUID you get in step 1
Would be much easier with syncUUIDs - but unfortunately it doesn't work for you :cry:
SeimusS
commented
3 days ago Looks like I am unlucky...
In regards of the manual update, you mean the UUID of the boot partition on the SDA drive?
$ sudo blkid
/dev/mmcblk0p1: SEC_TYPE="msdos" LABEL_FATBOOT="boot" LABEL="boot" UUID="AC15-4763" TYPE="vfat" PARTUUID="005bdc9a-01"
/dev/mmcblk0p2: LABEL="retropie" UUID="f1351d7a-72a6-4d65-b1e2-62653795df48" TYPE="ext4" PARTUUID="005bdc9a-02"
/dev/sda1: SEC_TYPE="msdos" UUID="41AD-DBBA" TYPE="vfat" PARTUUID="4c0ec3fc-01"
/dev/sda2: UUID="6163f313-c48d-49b4-aeaf-0310d143a069" TYPE="ext4" PARTUUID="4c0ec3fc-02"
/dev/mmcblk0: PTUUID="005bdc9a" PTTYPE="dos"
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root 57G 13G 42G 24% /
devtmpfs 3.7G 0 3.7G 0% /dev
tmpfs 3.9G 5.8M 3.9G 1% /dev/shm
tmpfs 3.9G 9.1M 3.9G 1% /run
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup
/dev/mmcblk0p1 256M 49M 207M 20% /boot
/dev/sda1 256M 49M 207M 20% /media/pi/sda1-usb-Argon_Forty_0000
/dev/sda2 228G 13G 204G 6% /media/pi/sda2-usb-Argon_Forty_0000
tmpfs 790M 0 790M 0% /run/user/1000
Problem is I see it empty...
pi@CZ-HRUS-RPi-DNS01:/media/pi/sda1-usb-Argon_Forty_0000 $ cat cmdline.txt
pi@CZ-HRUS-RPi-DNS01:/media/pi/sda1-usb-Argon_Forty_0000 $I am totally lost...
Regards, S.
framps
commented
3 days ago Use
vi /media/pi/sda1-usb-Argon_Forty_0000/cmdline.txt
to edit cmdline.txt
SeimusS
commented
3 days ago Problem is I do not know in which format to put it in. If I open the file in vi or nano I see only
@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
Regards, S.
SeimusS
commented
3 days ago Alright I was able to have this running.
As advised by @framps I hit two problems:
Funny enough my cmdline.txt on the SD as well after rpi-clone on SSD was like empty, it was showing @^@^@^@^@^.
I did however found a default cmdline.txt copied it and adjusted the PARTUUID with the one generated by rpi-clone. After this SSD booted properly.
cmdline.txt I found as "default", referrer to partition 2 rootfs
console=serial0,115200 console=tty1 root=PARTUUID=4c0ec3fc-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet init=/usr/lib/raspi-config/init_resize.sh
The 1st boot was a bit wongy waited 20min but it didn't boot, but after subsequent reboot, the disk was working totally fine and after next reboot the SSD boot immediately.
I must say I was extremely unlucky most of the time, with rpi-clone, as well the script. Not sure why none of it worked out of the box, but I am happy its working in the end!
@framps Many thanks to you that you stayed with me the whole time and advised me step by step, because I was going a bit insane. I hoped rpi-clone will be fast and easy... If you didn't helped me I would be still stucked.
Once again many thanks!!!
Regards, S.
framps
commented
3 days ago Glad you were able to fix the UUID issue 👍
I frankly have never seen a system which has garbage in cmdline.txt.
rpi-clone works perfektly for everybody but you 😢 Looks like you have something special in your environment which rpi-clone is not able to handle correctly. Unfortunately there exists no debug log in rpi-clone which may help to locate the root cause of your issue. I already created #32. Maybe somebody will take care of the issue.
Because cmdline.txt has garbage syncUUIDs fails. I will add some more code to write more details why syncUUIDs fails.
SeimusS
commented
3 days ago Yop I suspect that because cmdline.txt was basically "garbage" yet still device booted, that this maybe caused the fail of updating the cmdline.txt using rpi-clone and as well your script was failing on my system.
Honestly, I do not think there is anything special on my system, I run it as a DNS + docker, but never before touched cmdline.txt or fstab on it. I was running the RPI with SD since 2019 where in 2022 I did swap SD cards (old was dyeing) using dd to clone the SD to a NEW one. But as the current SD was showing as well its age and usage I decided to swap it with SSD, and that brought us here.
I will run few days the RPI from the SSD (root + boot) to see if its stable, and if yes. I will try to rpi-clone SSD to SD again with proper cmdline.txt to see if the cloning and adjusting will go correct.
@framps One again many thanks you are my hero!
I will close this topic as solved, hopefully nobody will hit problems like I did but if yes I hope the above sum-up https://github.com/geerlingguy/rpi-clone/issues/34#issuecomment-2208317299 will be helpful.
Regards, S.
Hello,
I try to clone my SD card to a SSD disk (Argon one case with the SSD adapter). But when I run rpi-clone I got the bellow error message. When I try to boot of the SSD only Pi will not come up. Does anybody know how to fix this?
Regards, S.