Can't boot | Copied System to a new ssd

Hello everyone,

I copied my system to a new ssd with dd. Unfortunately I can’t boot to the new ssd. The boot process starts the “Leap animation” and does that for a couple of minutes until it displays an grub error.
When I leave the old ssd plugged in and boot to the new one it works (selected the new one from bios).

When I look into /etc/fstab it shows me that all the important partitions are pointing to my new ssd:

UUID=ab0587dc-24ef-4ff6-b5b4-c1ad66fb401e       swap    swap    defaults 0 0 
UUID=500c6acf-86b4-4615-8b08-1d81573b29b9       /       btrfs   defaults 0 0 
UUID=500c6acf-86b4-4615-8b08-1d81573b29b9       /boot/grub2/i386-pc     btrfs   subvol=@/boot/grub2/i386-pc 0 0 
UUID=500c6acf-86b4-4615-8b08-1d81573b29b9       /boot/grub2/x86_64-efi  btrfs   subvol=@/boot/grub2/x86_64-efi 0 0 
UUID=500c6acf-86b4-4615-8b08-1d81573b29b9       /opt    btrfs   subvol=@/opt 0 0 
UUID=500c6acf-86b4-4615-8b08-1d81573b29b9       /srv    btrfs   subvol=@/srv 0 0 
UUID=500c6acf-86b4-4615-8b08-1d81573b29b9       /tmp    btrfs   subvol=@/tmp 0 0 
UUID=500c6acf-86b4-4615-8b08-1d81573b29b9       /usr/local      btrfs   subvol=@/usr/local 0 0 
UUID=500c6acf-86b4-4615-8b08-1d81573b29b9       /var/crash      btrfs   subvol=@/var/crash 0 0 
UUID=500c6acf-86b4-4615-8b08-1d81573b29b9       /var/lib/libvirt/images btrfs   subvol=@/var/lib/libvirt/images 0 0 
UUID=500c6acf-86b4-4615-8b08-1d81573b29b9       /var/lib/mailman        btrfs   subvol=@/var/lib/mailman 0 0 
UUID=500c6acf-86b4-4615-8b08-1d81573b29b9       /var/lib/mariadb        btrfs   subvol=@/var/lib/mariadb 0 0 
UUID=500c6acf-86b4-4615-8b08-1d81573b29b9       /var/lib/mysql  btrfs   subvol=@/var/lib/mysql 0 0 
UUID=500c6acf-86b4-4615-8b08-1d81573b29b9       /var/lib/named  btrfs   subvol=@/var/lib/named 0 0 
UUID=500c6acf-86b4-4615-8b08-1d81573b29b9       /var/lib/pgsql  btrfs   subvol=@/var/lib/pgsql 0 0 
UUID=500c6acf-86b4-4615-8b08-1d81573b29b9       /var/log        btrfs   subvol=@/var/log 0 0 
UUID=500c6acf-86b4-4615-8b08-1d81573b29b9       /var/opt        btrfs   subvol=@/var/opt 0 0 
UUID=500c6acf-86b4-4615-8b08-1d81573b29b9       /var/spool      btrfs   subvol=@/var/spool 0 0 
UUID=500c6acf-86b4-4615-8b08-1d81573b29b9       /var/tmp        btrfs   subvol=@/var/tmp 0 0 
UUID=500c6acf-86b4-4615-8b08-1d81573b29b9       /.snapshots     btrfs   subvol=@/.snapshots 0 0 
UUID=C56E-3A93  /boot/efi       vfat    umask=0002,utf8=true 0 0 

I looked into dmesq and found this:

    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.1.39-53-pv root=UUID=500c6acf-86b4-4615-8b08-1d81573b29b9 ...

This lets me believe that I’m booting from my new sdd but closer look into dmesg shows me that my old ssd is mounted and not my new one.

I did this before with Tumbleweed and it worked just fine. Maybe it’s because my new ssd is an nvme ssd. Or it’s because secure boot is enabled.

I guess at some point in the boot process the old ssd is needed.
If someone could point me in the right direction where I could find it that would be nice.

Regards,
Nico

When you copy raw disk you also duplicate filesystems UUIDs. Both GRUB and Linux use UUIDs to identify filesystems. So it is non-deterministic which filesystem instance of two identical copies they find. Moreover, you are risking real btrfs corruption trying to boot with to identical copies.

You will need to change UUID on your clone (it is possible using “btrfstune -u”) and then adjust both GRUB and Linux configuration to look for new UUID. Make sure only one correct copy is physically present in the system before using “btrfstune -u”.

a few years ago i had made a transfer system on another hdd, and make some notes about it:

Boot in rescue and mount new hdd, after what mount dev and proc, make chroot

>mount /dev/sda1 /system
>mount --bind /dev /system/dev
>mount --bind /proc /system/proc
>mount --bind /sys /system/sys
>mount --bind /run /system/run

>chroot /system

to fix hibernate correct value ‘resume=’ in file /etc/default/grub

correct /etc/fstab, and make grub2-mkconfig и grub2-install

>grub2-mkconfig -o /boot/grub2/grub.cfg

also need change /boot/grub2/device.map (if exist) and /etc/default/grub_installdevice.

after what make mkinitrd

checking inside files for value resume in /etc/sysconfig/bootloader и /etc/sysconfig/boot

Did you use dd as per part way down this link ? It seems it will also retain uuid’s.

https://wiki.archlinux.org/index.php/disk_cloning

;)I’m curious because I may want to do the same thing at some point.

John

for me it is not work. Trying clonzilla. After recover on another hdd, it not boot anymore

I’m not sure I understand that comment as I assume that the OP isn’t booting with the old drive in their machine so no duplicate UUID’s.

On UUID’s I don’t think that there is actually any need to use them. There are several options such by Label. It also seems that GRUB can cope with Labels rather than UUID’s as it is generally installed - not that I have seen any complete information on that aspect.

One aspect that might cause the OP problem is size. When people replace a drive it can sometimes be difficult to find one of the same size as the one that is replaced and often they may want a larger one anyway. Maybe dd can cope with this by effectively creating a partition of exactly the same size as the one that is being replaced - or maybe that aspect doesn’t matter. Given the various tables that may be on a disk though it could well be a problem. I assume though that partition size etc must be on the disk so should be copied leaving space if the new disk happens to be larger.

I wondered about clonezialla but noticed that it doesn’t mention btfrs but if it’s doing metal to metal and is running the machine itself maybe that doesn’t matter.

John

Thanks for the replies.

If dd copied the UUIDs it should be no problem (because grub also has the old UUIDs) to boot from the new ssd when the old one is not plugged in. Unfortunately I already tried that one and it didn’t worked.
What also made me wonder is that in /dev/disk the only device with UUID was the new ssd the old one was only in by-id.
So as far as I can tell this is not related to UUIDs.

I used dd as follows:

dd if=/dev/sdd of=/dev/nvme01 bs=1200M status=progress

The two ssds have exactly the same size in bytes. I set bs so high because the ssds are both m.2 via pcie and dd copied with a transfer rate of 800MB/s.

I will try clonezilla next.
And I will also look into the grub files that were mentioned.

Edit: May take some time because I have to take out my graphic card to get access to the ssds …

And what exactly happens when you try it? What error do you see, where does it stop? You are using EFI system which means there is at least one more step in boot process. Is ESP on the same SSD on or some third disk?

What also made me wonder is that in /dev/disk the only device with UUID was the new ssd the old one was only in by-id.

Of course there is only one device. There can be only one link with given name, and this link will point to the last device which was processed on boot. Which device will it be is not exactly deterministic.

> Edit: May take some time because I have to take out my graphic card to get access to the ssds …

wait… you do realise btrfs has built in tools to migrate itself to a new drive?

The boot aspect may have some problems. I suspect it’s not clear on a system with more than one disk which boot sector is used to get things up and running, It may relate in this respect to which disk the bios detects first. Hd0 etc. Hard to say as there is a lot of documentation about and some may be out of date or maybe it does work like that.

Personally I think it all aught to be boot and mount by label. It seems that grub can be persuaded to boot by label but from what little I have seen several files need to be edited by hand. It seems a bit odd to me that this can’t be done by editing one. :wink: Whoops I nearly typed perverse. (showing a deliberate and obstinate desire to behave in a way that is unreasonable or unacceptable) Grub is about the only aspect of Linux that makes me shake my head with sorrow.

John

Labels like UUID must be unique on the system you can not have two partitions with the same label or UUID running on the same system it confuses the system. Using Yast-partition manager you can set the symbology used. No more tweaking should be needed. Using by-id uses the disk ID thus should always be unique unless two disks have the same ID

Clonezilla did the trick. I wonder why.
I will look into the grub files if I find the time because I’m curious to find it out. If I find something that might relate to this I will post it here.

And what exactly happens when you try it? What error do you see, where does it stop?

I’m sorry I don’t know it exactly from the top of my head. Well it shows me the Leap bootup animation and after a couple of minutes it shows a grub boot error. Something like: “Error … Couldn’t boot”

wait… you do realise btrfs has built in tools to migrate itself to a new drive?

I didn’t know that but thanks for the information I appreciate it.

Labels like UUID must be unique on the system you can not have two partitions with the same label or UUID running on the same system it confuses the system.

I wasn’t planning to do that. It just occurred when I couldn’t boot so I put the old ssd back in.

If I should look for certain files on the old ssd please write me as soon as possible because I will reuse it as a cache for my freeNAS.

Was your boot partition marked as bootable?
If you still have your original disk, boot gparted live and inspect each partition on your disk, you will be informed which partition (if any) was marked bootable.

TSU

Was your boot partition marked as bootable?

The efi partition is marked bootable. It would be interesting to see if this was the case on the new ssd after dd.
That would explain why my motherboard didn’t want to boot from the new ssd after dd (when I choosed the drive directly). But there was no other option because it was the only boot option available so it booted from it after some time.
My motherboard is kinda buggy with booting from things so it didn’t bother me at all.

I will look into the grub files if I find the time because I’m curious to find it out. If I find something that might relate to this I will post it here.

Didn’t expect that I would do that tonight but I found something interesting.
I compared the files of the old and new ssd after I cloned it with clonezilla. Maybe I do the dd again and do another comparison.
The UUIDs are equal on booth ssds according to /etc/fstab and /dev/disk/by-uuid.
There is no differences in /etc/default/grub. There is also nothing suspicious in that file that would lead to this problem.
There is also no differences in /boot/grub2/grub.cfg. But in that file the UUID is used as expected.

The conclusion I draw from this is:
If dd copied the UUID there should be no problems what so ever to boot from it when the original ssd / hdd is not connected.
That didn’t worked for me in my first boot attempts that where without the original ssd. So dd either didn’t copy the UUID or there was read / write error.

If someone has other suggestions please let me know.
I won’t format the ssd until next weekend so if anyone wants me to have a look at some files let me know.

MBR or EFI booting? With EFI there is no need for a boot flag the BIOS looks for the special EFI boot partition formatted as FAT and starts the boot there.

MBR or EFI booting?

It is an EFI partition and it’s also marked as boot.

That didn’t worked for me in my first boot attempts that where without the original ssd. So dd either didn’t copy the UUID or there was read / write error.

I have to correct myself here. I looked into /dev/disk/by-uuid and the new ssd had the same uuid (after I cloned it with dd). So dd copied the uuid.

UUID is embedded in the first few sectors of every partition so if you dd a whole partition then the UUID is copied also. UUID changes every time a partition is created. I suspect your problem is that the UEFI/BIOS sees the new disk as different. It does have a different disk ID. And It’s boot table is not correct to boot from this new comer. Perhaps look at efibootmgr to see what the UEFI flash thinks it is booting. BTW man efibootmgr will show all your options and you can change the values in the UEFI flash with it. May need to run it from a live rescue disk.

The boot flag is not used in EFI booting but it also does not hurt. Not sure why it is set at all unless a MBR install was attempted sometime in the past.

Thanks again for the information. I will look into it and write a response (may take couple of days).
I can’t tell why the boot flag is set. I installed Leap 42.1 on this machine and didn’t upgrade from a prior version.

I’m sorry that it took so long for me to reply but I promised to look into this.

I suspect your problem is that the UEFI/BIOS sees the new disk as different. It does have a different disk ID. And It’s boot table is not correct to boot from this new comer.

gogalthrop I think you are right.