On 2023-03-19 19:57, Neil Rickert wrote:
On Sun, 19 Mar 2023 04:28:02 +0100 "Carlos E. R." <> wrote:
On 2023-03-19 02:25, Neil Rickert wrote:
Your UEFI BIOS probably did that.
No.
Then it would happened every day for years. It started to happen today, after an openSUSE update.
Perhaps it did happen every time, but you didn't notice.
It wouldn't boot, if it tried that directory, has the wrong files. That's what happened, tried to boot from it, failed, then switched to boot "auxiliary", which is 15.2 In fact, it has been altered again (after two hibernation cycles), but differently:
Telcontar:~ # efibootmgr -v BootCurrent: 0000 Timeout: 1 seconds BootOrder: 0000,0004,0005,0003 Boot0000* main-os-secureboot HD(1,GPT,800b649f-a2e3-4dad-b2bf-b7ecc5ef11d8,0x800,0xfa000)/File(\EFI\MAIN-OS\SHIM.EFI) Boot0001 Could not parse device path: No such file or directory Telcontar:~ #
Telcontar:~ # ls /boot/efi/EFI/ auxiliary boot main-os Telcontar:~ # l /boot/efi/EFI/ Now "auxiliary" and "boot" are gone from the efi list. It is booting "main-os" which happens to be the correct one. No idea what 0001 would be and what wrong device path is that one.
When that happens, "fallback.efi" is supposed to kick in to fix it. And you might not have noticed that this was going on.
May I suggest that you disable secure-boot in your BIOS until you get this working.
OpenSUSE 15.2 uses secure-boot signature from the openSUSE CA, while 15.3 and 15.4 use signatures from the SUSE CA. So there could be an incompatibility there.
This is supposed to be handled by enrolling a certificate. But that may have failed because you did not have "MokManager.efi" in the directory used for our Boot0003.
Telcontar:~ # l /boot/efi/EFI/main-os/ total 3176 drwxr-xr-x 2 root root 8192 Aug 10 2020 ./ drwxr-xr-x 5 root root 8192 Aug 10 2020 ../ -rwxr-xr-x 1 root root 846240 Mar 18 21:45 MokManager.efi* -rwxr-xr-x 1 root root 56 Mar 18 21:45 boot.csv* -rwxr-xr-x 1 root root 120 Mar 18 21:45 grub.cfg* -rwxr-xr-x 1 root root 1275904 Mar 18 21:45 grub.efi* -rwxr-xr-x 1 root root 143360 Mar 18 21:45 grubx64.efi* -rwxr-xr-x 1 root root 934680 Mar 18 21:45 shim.efi*
Those are likely to be okay.
This are the "UEFI OS" files;
Telcontar:~ # l /boot/efi/EFI/boot/ total 1552 drwxr-xr-x 2 root root 8192 Aug 10 2020 ./ drwxr-xr-x 5 root root 8192 Aug 10 2020 ../ -rwxr-xr-x 1 root root 1208968 Aug 10 2020 bootx64.efi* -rwxr-xr-x 1 root root 358768 Aug 10 2020 fallback.efi* Telcontar:~ #
Those probably come from 15.2 (based on the dates).
I am seeing:
# ls -l total 1832 -rwxr-xr-x 1 root root 934680 Dec 10 2021 bootx64.efi -rwxr-xr-x 1 root root 86352 Dec 10 2021 fallback.efi -rwxr-xr-x 1 root root 846240 Dec 10 2021 MokManager.efi
Those look old. But they are identical with the files from 15.4, as verified using "md5sum". The "bootx64.efi" is identical with the "shim.efi" from 15.4. And you can find "fallback.efi" at "/usr/share/efi/x86_64/fallback.efi".
I suggest you manually fix those files. And be consistent. Either they should all come from 15.2 or they should all come from 15.4. Mixing doesn't work.
I don't mix. I don't create nor ever touch that directory. I don't know how to tell the system to create it again. There should be a command to do it?
I have a Lenovo system (not my main desktop) which always wants to control the boot order. I can change the boot order with "efibootmgr" but it reverts on the next boot. But the BIOS settings do allow changing the boot order that the BIOS wants. You might have something similar happening.
Hum. Maybe.
If your 15.4 system happens to have kernel "5.14.21-150400.24.49" and if it uses Intel graphics, then it might not boot. However kernel "5.14.21-150400.24.46" should boot fine.
No, this machine has AMD graphics. Telcontar:~ # tree -sD /boot/efi/EFI/ /boot/efi/EFI/ ├── [ 8192 Mar 20 2020] auxiliary <== leap 15.2 │ ├── [ 846096 Mar 18 23:09] MokManager.efi │ ├── [ 60 Mar 18 23:09] boot.csv │ ├── [ 125 Mar 18 23:09] grub.cfg │ ├── [ 1193840 Mar 18 23:09] grub.efi │ ├── [ 139264 Mar 18 23:09] grubx64.efi │ └── [ 934024 Mar 18 23:09] shim.efi ├── [ 8192 Aug 10 2020] boot │ ├── [ 1208968 Aug 10 2020] bootx64.efi │ └── [ 358768 Aug 10 2020] fallback.efi └── [ 8192 Aug 10 2020] main-os <== leap 15.4 ├── [ 846240 Mar 18 21:45] MokManager.efi ├── [ 56 Mar 18 21:45] boot.csv ├── [ 120 Mar 18 21:45] grub.cfg ├── [ 1275904 Mar 18 21:45] grub.efi ├── [ 143360 Mar 18 21:45] grubx64.efi └── [ 934680 Mar 18 21:45] shim.efi The dates in 15.2 are correct, I updated the partition yesterday. Just had an idea, the efi partition may be corrupted, and yes, it is. (using quote, because it forces Thunderbird to disable wrap line)
Telcontar:~ # unmount /boot/efi Error: Try the command: umount Telcontar:~ # umount /boot/efi Telcontar:~ # fsck /dev/nvme0n1p1 fsck from util-linux 2.37.2 fsck.fat 4.1 (2017-01-24) 0x25: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt. 1) Remove dirty bit 2) No action ? ^CTelcontar:~ # fsck -a /dev/nvme0n1p1 fsck from util-linux 2.37.2 fsck.fat 4.1 (2017-01-24) 0x25: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt. Automatically removing dirty bit. Performing changes. /dev/nvme0n1p1: 40 files, 2321/63965 clusters Telcontar:~ #
still
Telcontar:~ # efibootmgr -v BootCurrent: 0000 Timeout: 1 seconds BootOrder: 0000,0004,0005,0003 Boot0000* main-os-secureboot HD(1,GPT,800b649f-a2e3-4dad-b2bf-b7ecc5ef11d8,0x800,0xfa000)/File(\EFI\MAIN-OS\SHIM.EFI) Boot0001 Could not parse device path: No such file or directory Telcontar:~ #
-- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)