20241119 unbootable host without manual grub2-install application
On updating one of my sandbox hosts from tw 20241010 to 20241119 level, reboot failed, throwing me into the dreaded grub rescue shell with this message:
error: ../../grub-core/kern/dl.c:382:symbol 'grub_is_cli_need_auth' not found.
The system has two disks, gpt formatted, sda1+sdb1 as "BIOS boot" partition for grub and sda2+sdb2 a RAID1 with LVM inside. Nothing unusual was seen on zypper dupping (I think... sorry, output not kept). I could repair the boot by rescue booting and running "grub2-install /dev/sda ; grub2-install /dev/sdb". Questions remaining: 1) isn't that supposed to work without manual intervention / rescue+grub2-install run? 2) general issue or something maybe related to my own setup (no fresh install for several years) Anything I could check to further understand this / hints on what I might do wrong? best regards Patrick
23.11.2024 19:54, Patrick Schaaf via openSUSE Factory wrote:
On updating one of my sandbox hosts from tw 20241010 to 20241119 level, reboot failed, throwing me into the dreaded grub rescue shell with this message:
error: ../../grub-core/kern/dl.c:382:symbol 'grub_is_cli_need_auth' not found.
The system has two disks, gpt formatted, sda1+sdb1 as "BIOS boot" partition for grub and sda2+sdb2 a RAID1 with LVM inside.
Nothing unusual was seen on zypper dupping (I think... sorry, output not kept).
I could repair the boot by rescue booting and running "grub2-install /dev/sda ; grub2-install /dev/sdb".
Questions remaining: 1) isn't that supposed to work without manual intervention / rescue+grub2-install run?
Show cat /etc/default/grub_installdevice
2) general issue or something maybe related to my own setup (no fresh install for several years)
Anything I could check to further understand this / hints on what I might do wrong?
best regards Patrick
On Sun, 24 Nov 2024 at 08:05, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
23.11.2024 19:54, Patrick Schaaf via openSUSE Factory wrote:
On updating one of my sandbox hosts from tw 20241010 to 20241119 level, reboot failed, throwing me into the dreaded grub rescue shell with this message:
Questions remaining: 1) isn't that supposed to work without manual intervention / rescue+grub2-install run?
Show cat /etc/default/grub_installdevice
teller:~ # cat /etc/default/grub_installdevice /dev/disk/by-id/ata-Crucial_CT512M550SSD3_14300DBBFA3A /dev/disk/by-id/ata-Samsung_SSD_840_PRO_Series_S12SNEAD111037L activate teller:~ # ls -l /dev/disk/by-id/ata- ata-Dogfish_SSD_2TB_2021051200363 ata-Dogfish_SSD_2TB_2021051200363-part1 ata-Dogfish_SSD_2TB_2021051200363-part2 ata-Samsung_SSD_870_QVO_4TB_S5STNF0T100691K ata-Samsung_SSD_870_QVO_4TB_S5STNF0T100691K-part1 ata-Samsung_SSD_870_QVO_4TB_S5STNF0T100691K-part2 ata-Samsung_SSD_870_QVO_4TB_S5STNF0T100691K-part3 OH. Aha! The device names in grub_installdevice are ... old/obsolete. So I just should fix them. Are these only created on install? Supposed to update automatically? If yes, I'd like to learn how my setup fails to do so! In any case, thanks for the hint !!! Patrick
24.11.2024 13:19, Patrick Schaaf wrote:
On Sun, 24 Nov 2024 at 08:05, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
23.11.2024 19:54, Patrick Schaaf via openSUSE Factory wrote:
On updating one of my sandbox hosts from tw 20241010 to 20241119 level, reboot failed, throwing me into the dreaded grub rescue shell with this message:
Questions remaining: 1) isn't that supposed to work without manual intervention / rescue+grub2-install run?
Show cat /etc/default/grub_installdevice
teller:~ # cat /etc/default/grub_installdevice /dev/disk/by-id/ata-Crucial_CT512M550SSD3_14300DBBFA3A /dev/disk/by-id/ata-Samsung_SSD_840_PRO_Series_S12SNEAD111037L activate teller:~ # ls -l /dev/disk/by-id/ata- ata-Dogfish_SSD_2TB_2021051200363 ata-Dogfish_SSD_2TB_2021051200363-part1 ata-Dogfish_SSD_2TB_2021051200363-part2 ata-Samsung_SSD_870_QVO_4TB_S5STNF0T100691K ata-Samsung_SSD_870_QVO_4TB_S5STNF0T100691K-part1 ata-Samsung_SSD_870_QVO_4TB_S5STNF0T100691K-part2 ata-Samsung_SSD_870_QVO_4TB_S5STNF0T100691K-part3
OH. Aha! The device names in grub_installdevice are ... old/obsolete. So I just should fix them.
Are these only created on install?
They are managed by YaST Bootloader module.
Supposed to update automatically? If
Update from what to what? They most certainly are not supposed to be updated by grub-install.
yes, I'd like to learn how my setup fails to do so!
In any case, thanks for the hint !!!
Patrick
On Sun, 24 Nov 2024 at 13:27, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
teller:~ # cat /etc/default/grub_installdevice
Are these only created on install?
They are managed by YaST Bootloader module.
Okay, makes sense. I pretty much ignore yast after install, in this case it's been many years ago, just using zypper dup.
Supposed to update automatically? If
Update from what to what? They most certainly are not supposed to be updated by grub-install.
I don't know, probably it would be hard to guess what to put there. I guess I was hoping something magical might be done (supposed to run) whenever grub packages get updated, and/or after boot, but I guess that was naive, especially for a more complex setup like mine. By now I also saw / vaguely remember I must have run into that on my production systems a while ago, because there we eventually ran into the issue that hardware raid volumes (HP smartarray) randomly switched between sda and sdb naming (if we have two logical arrays) - and I added something (systemd boottime service) to actually check (with knowledge about our further LVM setup and naming conventions, not generalizable) what the booted-from device is named on the current boot cycle - and write that name to both /boot/grub2/device.map and /etc/default/grub_installdevice. Just thought I type that in case someone runs into something similar. I'm happy with the situation, now I understand it (again). Thanks Andrei for your answers! best regards Patrick
participants (2)
-
Andrei Borzenkov -
Patrick Schaaf