[opensuse] Problem with booting a migrated machine.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I'm migrating an old computer to a new computer. First thing I did, was install openSUSE 15.1 on the new computer. Partition called "Auxiliary". Boots fine. Then, using this system, I cloned the old machine to the new machine. Well, only two partitions, "/" and "/boot" (not the others). Old machine (traditional BIOS, with GPT partitions): SSD disk. Two partitions to cope with, for the moment (*): /boot / sde sde 512 0 0 232.9G disk ├─sde1 sde1 512 0 0 24G part swap ssd-swap ssd-swap [SWAP] 4feaa6f5-38c4-4674-ae54-8e22389731a1 ├─sde2 sde2 512 0 0 15M part primary ├─sde3 sde3 512 0 0 15G part ext4 ssd-test primary / 32392d31-6b40-4f90-badd-9153370daba7 ├─sde4 * sde4 512 0 0 1G part ext2 ssd-boot primary /other/main/boot a977c5c3-259f-4df6-80e4-9f21a1ae96f5 └─sde5 * sde5 512 0 0 150G part ext4 ssd-main primary /other/main ac173013-18ad-4c4e-921e-fd2ecfb56495 New machine (UEFI): nvme disk. nvme0n1 nvme0n1 465,8G disk 0 0 ├─nvme0n1p1 nvme0n1p1 500M part 0 0 EFI EFI /boot/efi 1726-BDB2 ├─nvme0n1p2 nvme0n1p2 100G part 0 0 Swap Swap [SWAP] 7f9467db-113f-4ca5-867c-85113ce94da9 ├─nvme0n1p3 nvme0n1p3 30G part 0 0 Auxiliary Auxiliary / f0b68654-4d7f-4ff8-b68c-117e85bb5e7f ├─nvme0n1p4 nvme0n1p4 1G part 0 0 ssd-boot /other/main/boot a977c5c3-259f-4df6-80e4-9f21a1ae96f5 └─nvme0n1p5 nvme0n1p5 150G part 0 0 ssd-main /other/main ac173013-18ad-4c4e-921e-fd2ecfb56495 Partitions 4 and 5 of the old machine were cloned to the new machine, thus same uuid. I used this command: time dd bs=16M if=/dev/sde4 status=progress | ssh root@192.168.1.134 "dd bs=16M of=/dev/nvme0n1p4" time dd bs=16M if=/dev/sde5 status=progress | ssh root@192.168.1.134 "dd bs=16M of=/dev/nvme0n1p5" No errors. Now, the problem is getting that migrated system to boot, or for the moment, to at least start booting (it will not finish the booting, because it lacks the /home and data partitions, but those will be done later). I used mount bind sys, proc, dev and chrooted procedure to run yast in text mode and reinstall the boot loader in the cloned system. I then changed it to grub efi mode. It installed mokutil-0.3.0-lp151.5.1.x86_64.rpm. On the "auxiliary" system I used yast boot manager to probe for other systems. When booting, it does detect the cloned system but fails to boot it. The current error is (hand copied): error: file boot/vmlinuz-4-12-14-lp151...default` not found error: you need to load the kernel first. press any key to continue (but of course the file does exist, it must be looking at the wrong partition or something) I have this info: Andor:~ # efibootmgr -v BootCurrent: 0000 Timeout: 1 seconds BootOrder: 0000,0003,0001 Boot0000* opensuse-secureboot HD(1,GPT,800b649f-a2e3-4dad-b2bf-b7ecc5ef11d8,0x800,0xfa000)/File(\EFI\OPENSUSE\SHIM.EFI) Boot0001* auxiliary-secureboot HD(1,GPT,800b649f-a2e3-4dad-b2bf-b7ecc5ef11d8,0x800,0xfa000)/File(\EFI\AUXILIARY\SHIM.EFI) Boot0003* opensuse HD(1,GPT,800b649f-a2e3-4dad-b2bf-b7ecc5ef11d8,0x800,0xfa000)/File(\EFI\OPENSUSE\GRUBX64.EFI)..BO Andor:~ Booting directly from the UEFI menu fails. Press F11 when booting, then I get first a prompt to the UEFI password, then the menu. I select "opensuse-secureboot", it flashes something, and then goes to the grub menu of "Auxiliary" instead, so fast I can not see an error message. I also tried another method, that works on my BIOS+GPT machines (but not here). I create a "/boot/grub2/custom.cfg", with these two entries: menuentry '--> Auxiliary (por uuid)' --id cer-aux-001 { insmod part_gpt insmod ext2 set root='hd0,gpt2' if search --no-floppy --fs-uuid --set=root f0b68654-4d7f-4ff8-b68c-117e85bb5e7f ; then echo Going in sleep 3 chainloader +1 echo going out sleep 3 else echo Could not find this OS instance, will not boot (1) sleep 1 fi } menuentry '--> ssd-main (ssd-boot por uuid)' --id cer-nvme-002 { insmod part_gpt insmod ext4 set root='hd0,gpt3' if search --no-floppy --fs-uuid --set=root a977c5c3-259f-4df6-80e4-9f21a1ae96f5 ; then chainloader +1 else echo Could not find this OS instance, will not boot (2) sleep 1 fi } The entries do run but fail. I get "invalid EFI file path" just when "chainload" would be executed. Thus I gather that it doesn't work that way with UEFI. The entry created by os-prober in grub.cfg is this one (and it failed with this error: error: file boot/vmlinuz-4-12-14-lp151...default` not found error: you need to load the kernel first. press any key to continue ): ### BEGIN /etc/grub.d/30_os-prober ### menuentry 'openSUSE Leap 15.1 (on /dev/nvme0n1p5)' --class opensuse --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-ac173013-18ad-4c4e-921e-fd2ecfb56495' { insmod part_gpt insmod ext2 if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root ac173013-18ad-4c4e-921e-fd2ecfb56495 else search --no-floppy --fs-uuid --set=root ac173013-18ad-4c4e-921e-fd2ecfb56495 fi linuxefi /boot/vmlinuz-4.12.14-lp151.28.36-default root=/dev/nvme0n1p5 initrdefi /boot/initrd-4.12.14-lp151.28.36-default } I don't know where this is wrong. The uuid for root is correct, but there is a separate boot partition. On the original (Bios) system, the entry was: menuentry 'Main_openSUSE' --class main_opensuse --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-ac173013-18ad-4c4e-921e-fd2ecfb56495' { load_video set gfxpayload=keep insmod gzio insmod part_gpt insmod ext2 set root='hd0,gpt4' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-bios=hd4,gpt4 --hint-efi=hd4,gpt4 --hint-baremetal=ahci4,gpt4 --hint='hd0,gpt4' a977c5c3-259f-4df6-80e4-9f21a1ae96f5 else search --no-floppy --fs-uuid --set=root a977c5c3-259f-4df6-80e4-9f21a1ae96f5 fi echo 'Loading Linux 4.12.14-lp151.28.40-default ...' linux /vmlinuz-4.12.14-lp151.28.40-default root=UUID=ac173013-18ad-4c4e-921e-fd2ecfb56495 resume=/dev/disk/by-label/ssd-swap splash=verbose echo 'Loading initial ramdisk ...' initrd /initrd-4.12.14-lp151.28.40-default } Notice that the ancient version does: --set=root a977c5c3-259f-4df6-80e4-9f21a1ae96f5 (which is the /boot partition) while the new probed version does --set=root ac173013-18ad-4c4e-921e-fd2ecfb56495 (which is the root partition. This must be wrong). That must be the error (bug?) of os-prober. I'll add a manual entry in custom.cfg: menuentry '==> nvme-MAIN' --id cer-probe { insmod part_gpt insmod ext2 if search --no-floppy --fs-uuid --set=root a977c5c3-259f-4df6-80e4-9f21a1ae96f5 ; then linuxefi /boot/vmlinuz-4.12.14-lp151.28.36-default root=UUID=f0b68654-4d7f-4ff8-b68c-117e85bb5e7f splash=verbose resume=/dev/disk/by-label/Swap mitigations=auto initrdefi /boot/initrd-4.12.14-lp151.28.36-default else echo Could not find this OS instance, will not boot (3) sleep 1 fi } Yes, this entry does boot. Well, it starts to, till it finds (not) the missing disks, as expected. Progress! It remains to find why chainload does not work, and why directly from UEFI menu doesn't work either. I suspect YaST failed to enter the correct entry. Andor:/boot/grub2 # efibootmgr BootCurrent: 0000 Timeout: 1 seconds BootOrder: 0000,0003,0001,0004,0005 Boot0000* opensuse-secureboot <--- The correct name is "Main_openSUSE" Boot0001* auxiliary-secureboot Boot0003* opensuse Boot0004* UEFI: VerbatimSTORE N GO Boot0005* UEFI: VerbatimSTORE N GO, Partition 2 Andor:/boot/grub2 # - -- Cheers Carlos E. R. (from 15.1 x86_64 at Legolas) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXnWGYRwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVNooAnirM4WvkCQ2ZbNXH2Mj+ LMf38PaEAJ98jJLsTbyxb5KEuz8tkq960oHt9Q== =p6bp -----END PGP SIGNATURE-----
participants (1)
-
Carlos E. R.