UEFI / GRUB bootloader-id

[d146]

Hallo Leute,

da meine Server alle unter Debian laufen, bin ich auf Notebook und Desktop nach längerer Zeit mit Fedora nun auf siduction umgestiegen - herzlichen Dank ans siduction-Team für die tolle Distribution!
Bei meinem Desktop bin ich auf folgendes Problem gestoßen, wegen dem ich Euch um eine Info bitten möchte.

Der Rechner bootet über UEFI, die Platte ist in eine ESP, eine separate boot-Partition und eine Partition mit dem restlichen Plattenplatz (LUKS-encryptet mit darauf aufsetzendem LVM). Die Installation verlief ohne jegliche Probleme, nach dem ersten Start funktionierte alles. Daraufhin habe ich ein full-upgrade durchgeführt, das ebenfalls ohne Fehler durchlief.

Das Problem kam beim ersten Start des System nach dem full-upgrade: Das GRUB-Menü wurde gar nicht erst geladen - das System blieb in der GRUB-Shell hängen. Meine Vermutung: grub.cfg nicht gefunden. Ich konnte mit manueller Eingabe der Parameter das System von dort aus erst mal trotzdem starten. Nur: Wieso findet GRUB die .cfg nicht? Beim zweiten Boot-Versuch habe ich mal testhalber ein

Code: [Select]

insmod foo
in der GRUB-Shell eingegeben. Und siehe da: er suchte das im Pfad /EFI/debian/... Bei meiner ESP lagen grub.cfg und die .efi-Files aber im Directory '/EFI/siduction'. Also habe ich nach erneutem manuellen Booten mal das hier eingegeben:

Code: [Select]

grub-install --bootloader-id=debian /dev/sdaDamit war jetzt im BIOS/UEFI ein zusätzlicher Eintrag 'debian' zu sehen. Ich habe aber zunächst mal den schon vorher (ausschließlich) vorhandenen Eintrag 'siduction' weiterhin aktiv gelassen und das System damit gebootet - also wie bisher. Und siehe da: Plötzlich erscheint das GRUB-Menü und das Starten von siduction gelingt völlig problemlos.

Sorry für die lange Vorrede. Aber da ich kein GRUB-Guru bin, würde mich interessieren:

- Warum sucht GRUB die grub.cfg im Ordner 'debian', obwohl ich 'siduction' boote (hier hatte ich ja keinerlei Änderungen vorgenommen und alles mit den siduction-Defaults installiert)?

- Ich mache jetzt nach Updates immer sicherheitshalber das o. g. grub-install ... Denn standardmäßig wird nach Updates immer nur das siduction-Directory aktualisiert. Mir wäre aber wohler, wenn ich den Grund für das zusätzlich erforderliche 'debian' kennen würde und damit vielleicht sogar wüsste, wie ich das quasi bereinigen kann. Denn so ganz koscher scheint mir das nicht zu sein.

Ich wäre Euch für jegliche Hinweise dankbar. Vielleicht habe ich ja auch nur irgendwas übersehen, falsch konfiguriert etc.

[melmarker]

chrooten und den grub-install mit parameter

Code: [Select]

grub-install --no-uefi-secure-boot

wenn ich mich recht entsinne - so was passiert, wenn Downstreams wie Debian neue Parameter erfinden und das neue Verhalten mit signiertem Kernel als default setzen, ohne da ordentlich zu dokumentieren.

[d146]

Vielen Dank für Deine schnelle Antwort! :-)

Habe mal beide Verzeichnisse unterhalb von /boot/efi/EFI umbenannt und dann den Befehl ausgeführt. Damit gibt es jetzt nur noch das dadurch wieder neu angelegte 'siduction' mit darin befindlicher grubx64.efi. Den bisher zusätzlichen UEFI-Eintrag 'debian' habe ich der Vollständigkeit halber mit efibootmgr entfernt - damit ist auch das bereinigt. Und das gerade gekommene Kernel-Update linux-image-siduction-amd64 (5.1-8 => 5.1-9) lief ohne Probleme. Damit sollte das jetzt wohl alles passen. :-)

Danke noch mal und viele Grüße!

[melmarker]

och - debian würde schon fein funktionieren so out of the box - mit einem signierten Kernel und -modulen natürlich

Dass die Jungens auch immer so fürchterlich übertreiben müssen, wenn sie mal was auf die Reihe bekommen haben - so nach Jahren

[d146]

 
Wobei ich sagen muss: Ich hatte neben den Servern Debian jahrelang auch auf Notebooks und Desktops (Squeeze, Wheezy, Jessie und vor vielen, vielen Jahren Sidux) - speziell was das Booten betraf, gab es da nie Probleme.

Und bei siduction jetzt ja auch nicht mehr, danke!