grub uefi RAID Fallback-ESP bootet nur in grub-shell

[Theophil T.]

Hallo,

in einem neu aufgesetzten Server im UEFI-Modus sind 2 HDD's installiert und Debian Bullseye amd64.

/ liegt auf einem RAID 1 (sda3 und sdb3)
Die erste, bei der Installation eingerichtete ESP ist sda1

sdb1 habe ich als Fallback-ESP bei Ausfall von sda eingerichtet. Diese ist unter /boot/efi-sdb1 gemountet. Grub ist dort installiert mit

Code: Alles auswählen

grub-install --bootloader-id=debian-efi-sdb1 --efi-directory=/boot/efi-sdb1  /dev/sdb1

Beim Testen der Konfiguration geschieht Folgendes:
Auswahl des Fallback-Eintrages im UEFI-Bootmenu, dies startet Grub nur in die grub-shell, nicht in das übliche Grub-Bootmenu.
Ich kann aus der shell das System von Hand starten:

Code: Alles auswählen

set root=(md/1)
linux /boot/vmlinuz-5.9.0-1-amd64 root=/dev/md1
initrd /boot/initrd.img-5.9......
boot

Die Konfigurationsdateien sind in beiden Grub-Installationen identisch:

Code: Alles auswählen

cat /boot/efi/EFI/debian/grub.cfg 
search.fs_uuid 0961177b-d72e-4436-8d1d-7589233146e6  root mduuid/f88f5ec53fe0c1e2900097bfa1539ed4 
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg

cat /boot/efi-sdb1/EFI/debian-efi-sdb1/grub.cfg 
search.fs_uuid 0961177b-d72e-4436-8d1d-7589233146e6  root mduuid/f88f5ec53fe0c1e2900097bfa1539ed4 
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg

Woran kann es liegen, dass das System mit der ersten in üblicher Weise eingerichteten ESP normal bootet, mit der Fallback-ESP aber "von Hand" aus der Grub-shell gestartet werden muss?
Mit meinen bisherigen Recherchen habe ich noch keine Antwort gefunden.

Viele Grüße Theophil

Edit: grub-shell Boot-Befehle korrigiert

[bluestar]

Was sagt denn efibootmgr -v?

[Theophil T.]

Code: Alles auswählen

efibootmgr -v
BootCurrent: 0000
Timeout: 3 seconds
BootOrder: 0000,0007,0004,0003,0001,0002
Boot0000* debian        HD(1,GPT,9cf9017c-2d6c-4a54-a650-4b672614c962,0x800,0xee000)/File(\EFI\DEBIAN\SHIMX64.EFI)
Boot0001  Hard Drive    BBS(HD,,0x0)/VenHw(5ce8128b-2cec-40f0-8372-80640e3dc858,0200)..GO..NO..........S.T.8.0.0.0.N.E.0.0.1.....
Boot0002  Network Card  BBS(Network,,0x0)/VenHw(5ce8128b-2cec-40f0-8372-80640e3dc858,0600)..GO..NO.....
Boot0003* UEFI: Built-in EFI Shell      VenMedia(5023b95c-db26-429b-a648-bd47664c8012)..BO
Boot0004* debian-efi-sdb1       HD(1,GPT,2b1f2953-2dd1-4045-946d-0155bf6d5b8d,0x800,0xee000)/File(\EFI\debian-efi-sdb1\shimx64.efi)
Boot0007* debian        HD(1,GPT,9cf9017c-2d6c-4a54-a650-4b672614c962,0x800,0xee000)/File(\EFI\DEBIAN\GRUBX64.EFI)..BO

[bluestar]

Versuch es mal mit einer Bootloader-id, die kürzer als 8 Zeichen ist.

[Theophil T.]

Das will ich gern versuchen.

Ich überlege nur Folgendes:
Die Firmware startet ja Grub, d.h. die Grub-Shell ist "in sich ordnungsgemäß" da. Also sollte die UEFI-Firmware an der Stelle doch eigentlich schon aus dem Rennen sein. In [1] wird beschrieben:

... When you boot up your system and it stops at
the grub> prompt, that is the full GRUB 2 command shell.
That means GRUB 2 started normally and loaded
the normal.mod module (and other modules which are
located in /boot/grub/[arch]/), but it didn’t find
your grub.cfg file. ...

Könnte der Fehler deshalb nicht eher mit Grub zusammenhängen, also mit dem im Artikel genannten Problem, das /boot/grub/grub.cfg nicht gefunden wird?


1 https://www.linux.com/training-tutorial ... b-2-linux/

[Theophil T.]

Habe es mit einer Bootloader-ID < 8 Zeichen getestet, das Resultat hat sich nicht geändert.

Bisherige EFI-Booteinträge und Daten der ESPs gelöscht

Code: Alles auswählen

grub-install --bootloader-id debian /dev/sda1
grub-install --bootloader-id deb-e2 --efi-directory=/boot/efi2 /dev/sdb1
update-grub
efibootmgr -o XXXX,....
efibootmgr -v
BootCurrent: 0000
Timeout: 3 seconds
BootOrder: 0000,0004,0005,0003,0001,0002
Boot0000* debian        HD(1,GPT,2b1f2953-2dd1-4045-946d-0155bf6d5b8d,0x800,0xee000)/File(\EFI\DEBIAN\SHIMX64.EFI)
Boot0001  Hard Drive    BBS(HD,,0x0)/VenHw(5ce8128b-2cec-40f0-8372-80640e3dc858,0200)..GO..NO..
Boot0002  Network Card  BBS(Network,,0x0)/VenHw(5ce8128b-2cec-40f0-8372-80640e3dc858,0600)..GO..NO....
Boot0003* UEFI: Built-in EFI Shell      VenMedia(5023b95c-db26-429b-a648-bd47664c8012)..BO
Boot0004* deb-e2        HD(1,GPT,9cf9017c-2d6c-4a54-a650-4b672614c962,0x800,0xee000)/File(\EFI\deb-e2\shimx64.efi)
Boot0005* debian        HD(1,GPT,2b1f2953-2dd1-4045-946d-0155bf6d5b8d,0x800,0xee000)/File(\EFI\DEBIAN\GRUBX64.EFI)..BO

Ich vermute weiterhin, dass die Ursache bei Grub selbst liegt. Gut, das Problem ist jetzt nicht so existenziell, bei Ausfall von der ersten Festplatte muss ich dann halt einmal von Hand booten. Es wäre halt nur etwas praktischer und mich interessiert, wie es zu diesem Verhalten kommt.

Trotzdem vielen Dank für Deinen Vorschlag!

[Theophil T.]

Nach Start via ESP auf /dev/sdb1 (grub-shell) sind die Mountpunkte /dev/sda1 und /dev/sdb1 vertauscht!
Die Einträge in /etc/fstab sind korrekt, d.h. /dev/sda1 sollte auf /boot/efi gemountet sein, /dev/sdb1 auf /boot/efi2.

Eigenartig, ich werde in Kürze noch mal einen Test nach [1] machen mit nur einem Mountpunkt und identischer Bootloader-ID.


1 https://www.thomas-krenn.com/de/wiki/Ub ... r%C3%A4gen

[Theophil T.]

Identische Bootloader-ID geht nicht, dann bekommt man keine 2 Einträge im UEFI-Bootmenu.

Offensichtlich sind nach Start von einer anderen ESP die Dateisystem-UUIDs der ESPs und damit die Mountpunkte /dev/sda1 und /dev/sdb1 vertauscht! Soweit ich mich nach den ganzen Versuchen erinnere wechseln die Mountpunkte sogar, falls die Partitionen in /etc/fstab als /dev/sd{a,b}1 eingetragen sind.

Ich habe das aber nicht mehr weiter geprüft, für den relativ kleinen Vorteil ist mir zur Zeit der Aufwand dafür zu hoch.

PS: Vielleicht ist dies von den Entwicklern so beabsichtigt, um immer die aktive ESP gemountet zu haben.
Die Ursache, dass grub von der 2. ESP nur in die shell startet, ist mir allerdings weiter unklar, evtl. steckt eine ähnliche Überlegung dahinter.