Well I think I have found the problem and it is cmdline.txt & the PARTUUID.
I did a off-server SD Copy and the clone worked. Then overnight it did the framps rpi-clone update. The clone then would not boot. The clue was in the rpi-clone output:
Destination disk has same Disk ID as source, changing it.
Disk identifier changed from 0x6xxxxxxx to 0xbxxxxxx [obfuscated]
It had changed /etc/fstab but it had not changed cmdline.txt to the same PARTUUID. It was using the source PARTUUID. Editing that and hey presto - successful boot. The issue now is that every time I re-clone it the cmdline.txt will revert. I could add an extra command to my cloning script to correct it - or just make a note to edit it if I ever have to use the clone in anger. Trouble is using backup is a time of stress because you have failed to sort the source disk problem. I guess a big post-it note may be the easiest way forward. From experience:
"if you have backups you probably won't need them but if you haven't you certainly will"
I did a off-server SD Copy and the clone worked. Then overnight it did the framps rpi-clone update. The clone then would not boot. The clue was in the rpi-clone output:
Destination disk has same Disk ID as source, changing it.
Disk identifier changed from 0x6xxxxxxx to 0xbxxxxxx [obfuscated]
It had changed /etc/fstab but it had not changed cmdline.txt to the same PARTUUID. It was using the source PARTUUID. Editing that and hey presto - successful boot. The issue now is that every time I re-clone it the cmdline.txt will revert. I could add an extra command to my cloning script to correct it - or just make a note to edit it if I ever have to use the clone in anger. Trouble is using backup is a time of stress because you have failed to sort the source disk problem. I guess a big post-it note may be the easiest way forward. From experience:
"if you have backups you probably won't need them but if you haven't you certainly will"
Statistics: Posted by brainsys — Sun Jan 21, 2024 1:55 pm