Fwd: Re: [opensuse] Grub crashes just after update (15.1) - something is reverting my changes to EFI BIOS order
On 8/10/20 1:55 PM, Carlos E. R. wrote:
On 10/08/2020 15.16, JJM de Faber wrote:
On 10-08-2020 15:06, Carlos E. R. wrote:
On 10/08/2020 14.02, Carlos E. R. wrote:
On Monday, 2020-08-10 at 13:37 +0200, Carlos E. R. wrote:
...
long snip
Thanks, but that doesn't solve the issue that something is changing what I write there, and trying to boot something else instead of openSUSE.
Just a wild guess . . . is it possible that device.map is the cuprit? If the grub install is incorrectly determining the boot order from its bios guess (when there is no device.map file) or there is an incorrect device.map file present, it is possible that the wrong location will be called. Or possibly grub2-mkconfig put an error in the grub.cfg file?
--dg
On 10-08-2020 20:31, DennisG wrote:
On 8/10/20 1:55 PM, Carlos E. R. wrote:
On 10/08/2020 15.16, JJM de Faber wrote:
On 10-08-2020 15:06, Carlos E. R. wrote:
On 10/08/2020 14.02, Carlos E. R. wrote:
On Monday, 2020-08-10 at 13:37 +0200, Carlos E. R. wrote:
...
long snip
Thanks, but that doesn't solve the issue that something is changing what I write there, and trying to boot something else instead of openSUSE.
Just a wild guess . . . is it possible that device.map is the cuprit? If the grub install is incorrectly determining the boot order from its bios guess (when there is no device.map file) or there is an incorrect device.map file present, it is possible that the wrong location will be called. Or possibly grub2-mkconfig put an error in the grub.cfg file?
--dg There is no devicemap in grub2
On 10/08/2020 20.31, DennisG wrote:
On 8/10/20 1:55 PM, Carlos E. R. wrote:
On 10/08/2020 15.16, JJM de Faber wrote:
On 10-08-2020 15:06, Carlos E. R. wrote:
On 10/08/2020 14.02, Carlos E. R. wrote:
On Monday, 2020-08-10 at 13:37 +0200, Carlos E. R. wrote:
...
long snip
Thanks, but that doesn't solve the issue that something is changing what I write there, and trying to boot something else instead of openSUSE.
Just a wild guess . . . is it possible that device.map is the cuprit? If the grub install is incorrectly determining the boot order from its bios guess (when there is no device.map file) or there is an incorrect device.map file present, it is possible that the wrong location will be called. Or possibly grub2-mkconfig put an error in the grub.cfg file?
No device map in efi/grub.
My current culprit is either the BIOS is altering the list for some reason of its own, or some automatic process in openSUSE is doing it. There is no other explanation.
#1 seems the most probable, as when I edit the list in the BIOS itself, then it works. So the program "efibootmgr" is doing something the BIOS doesn't accept.
What I will do next is use a shorter name without the "_" char.
On 8/10/20 2:41 PM, JJM de Faber wrote:
On 10-08-2020 20:31, DennisG wrote:
On 8/10/20 1:55 PM, Carlos E. R. wrote:
On 10/08/2020 15.16, JJM de Faber wrote:
On 10-08-2020 15:06, Carlos E. R. wrote:
On 10/08/2020 14.02, Carlos E. R. wrote:
On Monday, 2020-08-10 at 13:37 +0200, Carlos E. R. wrote:
...
long snip
Thanks, but that doesn't solve the issue that something is changing what I write there, and trying to boot something else instead of openSUSE.
Just a wild guess . . . is it possible that device.map is the cuprit? If the grub install is incorrectly determining the boot order from its bios guess (when there is no device.map file) or there is an incorrect device.map file present, it is possible that the wrong location will be called. Or possibly grub2-mkconfig put an error in the grub.cfg file?
--dg There is no devicemap in grub2
From the GRUB manual:
"GRUB avoids this problem nowadays by using UUIDs or file system labels when generatinggrub.cfg, and we advise that you do the same for any custom menu entries you write. If the device map file does not exist, then the GRUB utilities will assume a temporary device map on the fly. This is often good enough, particularly in the common case of single-disk systems . . . However, the device map file is not entirely obsolete yet, and it is used for overriding when current environment is different from the one on boot."
From openSUSE 15.2 documentation:
"GRUB 2 avoids this problem by using device ID strings (UUIDs) or file system labels when generating|grub.cfg|. GRUB 2 utilities create a temporary device map on the fly, which is usually sufficient, particularly in the case of single-disk systems.
However, if you need to override the GRUB 2's automatic device mapping mechanism, create your custom mapping file|/boot/grub2/device.map."|
| |
|So . . . if the device.map is there, it will be used. And if it is not present but grub installation guesses wrong, then the virtual device map is wrong, too.|
| |
|What am I missing?|
| |
|--dg |
| |
| |
On 8/10/20 2:53 PM, Carlos E.R. wrote:
On 10/08/2020 20.31, DennisG wrote:
On 8/10/20 1:55 PM, Carlos E. R. wrote:
On 10/08/2020 15.16, JJM de Faber wrote:
On 10-08-2020 15:06, Carlos E. R. wrote:
On 10/08/2020 14.02, Carlos E. R. wrote:
On Monday, 2020-08-10 at 13:37 +0200, Carlos E. R. wrote:
...
>> long snip
Thanks, but that doesn't solve the issue that something is changing what I write there, and trying to boot something else instead of openSUSE.
Just a wild guess . . . is it possible that device.map is the cuprit? If the grub install is incorrectly determining the boot order from its bios guess (when there is no device.map file) or there is an incorrect device.map file present, it is possible that the wrong location will be called. Or possibly grub2-mkconfig put an error in the grub.cfg file?
No device map in efi/grub.
My current culprit is either the BIOS is altering the list for some reason of its own, or some automatic process in openSUSE is doing it. There is no other explanation.
#1 seems the most probable, as when I edit the list in the BIOS itself, then it works. So the program "efibootmgr" is doing something the BIOS doesn't accept.
What I will do next is use a shorter name without the "_" char.
Another wild guess: Problem with filesystem labels or UUID's? Grub2-mkconfig uses one or the other of those to build grub.cfg.
--dg
Carlos E.R. composed on 2020-08-10 20:53 (UTC+0200):
What I will do next is use a shorter name without the "_" char.
KISS (pure ASCII alphanumerics) WFM.:
# inxi -S System: Host: gb250 Kernel: 5.6.14-1-default x86_64 bits: 64 Desktop: Trinity R14.0.8 Distro: openSUSE Tumbleweed 20200628 # efibootmgr BootCurrent: 0000 Timeout: 1 seconds BootOrder: 0000,0005,0003,0004 Boot0000* opensusetw Boot0003* Hard Drive Boot0004* CD/DVD Drive Boot0005* opensuse152 # ls -1 /boot/efi/EFI/ BOOT debian10 opensuse152 opensusetw ubuntu2004
Is there any ambiguity in the meaning of any of these?
On 10/08/2020 21.08, DennisG wrote:
On 8/10/20 2:53 PM, Carlos E.R. wrote:
On 10/08/2020 20.31, DennisG wrote:
Another wild guess: Problem with filesystem labels or UUID's? Grub2-mkconfig uses one or the other of those to build grub.cfg.
No.
It is not a problem with Grub.
My problem is solely with the EFI entries in the flash memory of the machine BIOS (UEFI, actually). I write a boot order with "efibootmgr" command in Linux, and "something" else changes the order to something else that does not boot (because it prefers an ancient entry that can not call the current grub2 after it was patched for that vulnerability).
I don't know what is that "something". A process in Linux, or the firmware of the machine. Probably the later.
Anyway, all my disks and partitions have both UUIDs and Labels. Specially the nvme disk that holds the system and boots the machine.
On 10/08/2020 21.27, Felix Miata wrote:
Carlos E.R. composed on 2020-08-10 20:53 (UTC+0200):
What I will do next is use a shorter name without the "_" char.
KISS (pure ASCII alphanumerics) WFM.:
# inxi -S System: Host: gb250 Kernel: 5.6.14-1-default x86_64 bits: 64 Desktop: Trinity R14.0.8 Distro: openSUSE Tumbleweed 20200628 # efibootmgr BootCurrent: 0000 Timeout: 1 seconds BootOrder: 0000,0005,0003,0004 Boot0000* opensusetw Boot0003* Hard Drive Boot0004* CD/DVD Drive Boot0005* opensuse152 # ls -1 /boot/efi/EFI/ BOOT debian10 opensuse152 opensusetw ubuntu2004
Is there any ambiguity in the meaning of any of these?
Is there any in mine?
Boot0000* main_opensuse-secureboot Boot0004* opensuse
I wrote the name "main_opensuse", it is here:
Telcontar:~ # grep GRUB_DISTRIBUTOR /etc/default/grub GRUB_DISTRIBUTOR="Main_openSUSE" Telcontar:~ #
Then openSUSE added the "-secureboot" part.
The "Boot0004* opensuse" entry is the original entry created by the installation. As I have two openSUSE systems in the same disk, and they both use the same "opensuse" name, I renamed both to something else (one "main_openSUSE", another "Auxiliary".
(note that something also deleted "Auxiliary"
The program "efibootmgr" doesn't complain of any problem with chars or lengths, but something else is changing the default "0000" to "0004", which fails because it is obsolete.
If I delete that obsolete entry, that "something" again changes the default "0000" to boot a new entry it creates, "0001":
Boot0001 UEFI OS
that boots "/boot/efi/EFI/boot/bootx64.efi".
Telcontar:~ # cat /boot/efi/EFI/boot/grub.cfg set btrfs_relative_path="yes" search --fs-uuid --set=root a977c5c3-259f-4df6-80e4-9f21a1ae96f5 set prefix=(${root})/grub2 source "${prefix}/grub.cfg" Telcontar:~ #
That root is my /boot partition, same one as used by "Main_openSUSE", but the files are dated on March, so it will not boot.
I will now set the name to "MainoS", but I want to use a separator between the two words, say "main-os", all lowercase. And the other to "aux".
Without a separator the text is not clear to me.
Notice that the whatever changed the BIOS wrote " UEFI OS" with a space. I did not use spaces.
Trying.
Telcontar:~ # grub2-mkconfig -o /boot/grub2/grub.cfg Generating grub configuration file ... Found theme: /boot/grub2/themes/openSUSE/theme.txt Found linux image: /boot/vmlinuz-4.12.14-lp151.28.59-default Found initrd image: /boot/initrd-4.12.14-lp151.28.59-default Found linux image: /boot/vmlinuz-4.12.14-lp151.28.52-default Found initrd image: /boot/initrd-4.12.14-lp151.28.52-default ... Found openSUSE 11.4 (x86_64) on /dev/sdb4 done Telcontar:~ #
Telcontar:~ # ls /boot/efi/EFI/ auxiliary boot main_opensuse no_opensuse Telcontar:~ #
Not enough. No change in "efibootmgr". I will use YaST instead.
Telcontar:~ # ls /boot/efi/EFI/ auxiliary boot main-os main_opensuse no_opensuse Telcontar:~ #
Telcontar:~ # efibootmgr -v BootCurrent: 0000 Timeout: 1 seconds BootOrder: 0002,0000,0001 Boot0000* main_opensuse-secureboot HD(1,GPT,800b649f-a2e3-4dad-b2bf-b7ecc5ef11d8,0x800,0xfa000)/File(\EFI\MAIN_OPENSUSE\SHIM.EFI) Boot0001 UEFI OS HD(1,GPT,800b649f-a2e3-4dad-b2bf-b7ecc5ef11d8,0x800,0xfa000)/File(\EFI\BOOT\BOOTX64.EFI)..BO Boot0002* main-os-secureboot HD(1,GPT,800b649f-a2e3-4dad-b2bf-b7ecc5ef11d8,0x800,0xfa000)/File(\EFI\main-os\shim.efi) Telcontar:~ #
Huh. I will remove obsolete directories: \EFI\MAIN_OPENSUSE, \EFI\BOOT, and try again.
Telcontar:~ # l /boot/efi/EFI/ total 48 drwxr-xr-x 5 root root 8192 Aug 10 22:43 ./ drwxr-xr-x 4 root root 16384 Aug 10 22:41 ../ drwxr-xr-x 2 root root 8192 Mar 20 19:30 auxiliary/ drwxr-xr-x 2 root root 8192 Aug 10 22:43 boot/ drwxr-xr-x 2 root root 8192 Aug 10 22:39 main-os/ Telcontar:~ #
Huh. Something created "boot" again, but this time with current files.
Telcontar:~ # efibootmgr -v BootCurrent: 0000 Timeout: 1 seconds BootOrder: 0002,0000,0001 Boot0000* main_opensuse-secureboot HD(1,GPT,800b649f-a2e3-4dad-b2bf-b7ecc5ef11d8,0x800,0xfa000)/File(\EFI\MAIN_OPENSUSE\SHIM.EFI) Boot0001 UEFI OS HD(1,GPT,800b649f-a2e3-4dad-b2bf-b7ecc5ef11d8,0x800,0xfa000)/File(\EFI\BOOT\BOOTX64.EFI)..BO Boot0002* main-os-secureboot HD(1,GPT,800b649f-a2e3-4dad-b2bf-b7ecc5ef11d8,0x800,0xfa000)/File(\EFI\main-os\shim.efi) Telcontar:~ #
I will delete that "UEFI OS" entry, and the "main_opensuse-secureboot" entry.
Telcontar:~ # efibootmgr -b 1 -B BootCurrent: 0000 Timeout: 1 seconds BootOrder: 0002,0000 Boot0000* main_opensuse-secureboot Boot0002* main-os-secureboot Telcontar:~ #
And I have, finally:
Telcontar:~ # efibootmgr -v BootCurrent: 0000 Timeout: 1 seconds BootOrder: 0002 Boot0002* main-os-secureboot HD(1,GPT,800b649f-a2e3-4dad-b2bf-b7ecc5ef11d8,0x800,0xfa000)/File(\EFI\main-os\shim.efi) Telcontar:~ #
Now I will reboot, and find out if "something" again changes the entries. If it does, I will enter the BIOS to put the order correct, manually.
On 10/08/2020 22.56, Carlos E. R. wrote:
On 10/08/2020 21.27, Felix Miata wrote:
Carlos E.R. composed on 2020-08-10 20:53 (UTC+0200):
...
And I have, finally:
Telcontar:~ # efibootmgr -v BootCurrent: 0000 Timeout: 1 seconds BootOrder: 0002 Boot0002* main-os-secureboot HD(1,GPT,800b649f-a2e3-4dad-b2bf-b7ecc5ef11d8,0x800,0xfa000)/File(\EFI\main-os\shim.efi) Telcontar:~ #
Now I will reboot, and find out if "something" again changes the entries. If it does, I will enter the BIOS to put the order correct, manually.
Well, it booted, but something added one entry:
Telcontar:~ # efibootmgr -v BootCurrent: 0002 Timeout: 1 seconds BootOrder: 0002,0003 Boot0002* main-os-secureboot HD(1,GPT,800b649f-a2e3-4dad-b2bf-b7ecc5ef11d8,0x800,0xfa000)/File(\EFI\MAIN-OS\SHIM.EFI) Boot0003* UEFI OS HD(1,GPT,800b649f-a2e3-4dad-b2bf-b7ecc5ef11d8,0x800,0xfa000)/File(\EFI\BOOT\BOOTX64.EFI)..BO Telcontar:~ #
But the order is respected, so I can live with that.
It remains to add back the Auxiliary Linux, which acts as rescue system.
-
Carlos E. R. -
Carlos E.R. -
DennisG -
Felix Miata -
JJM de Faber