Ihr habt ein Kernel Update eingespielt bekommen, aber der Default-Kernel ist immer noch der „alte“ Kernel? Willkommen in der digitalen Steinzeit der Grubby Bugs.

Wie man einen Default Kernel setzen kann

Per Mail erreichte mich eine Anfrage zu Grubby, das ist das kleine Tool, das sich um die Grub Booteinträge kümmert. In der Anfrage ging ein Kernel-Update schief und der Default Kernel lies sich nicht setzen. Die Ursache liegt in einem „Steinzeit“-Fehler: Der Grubenv Block ist wie in Stein gemeiselt genau 1024 Bytes lang, egal was sinnvolles drin steht 🙂

Jetzt ist der Bug an sich nichts neues, da reden der Redhat Support, die Fedora Maintainer und die Grubby Devs gefühlt schon eine Ewigkeit drüber. In etlichen Bugreports gibt es einen gemeinsamen Nenner: Grubby und nicht 1024 Bytes große grubenv Dateien 🙂

Wenn man jetzt versucht einen Default-Kernel zu setzen, kann man Opfer dieses Bugs werden und keiner sagt es einem, außer der schon gehässigen Regelmäßigkeit, mit der der alte Kernel gebootet wird. Beispiel:

[root@eve]# grubby --default-kernel
/boot/vmlinuz-5.2.7-100.fc29.x86_64
[root@eve]# grubby --set-default=/boot/vmlinuz-5.2.11-100.fc29.x86_64
[root@eve]# grubby --default-kernel
/boot/vmlinuz-5.2.7-100.fc29.x86_64
[root@eve]# cat /boot/grub2/grubenv
# GRUB Environment Block
saved_entry=Fedora (5.2.7-100.fc29.x86_64) 29 (Twenty Nine)
"

[root@eve#

Die Methode mit der man den Kernel als Default setzen will, spielt dabei keine Rolle:

[root@eve]# grubby --set-default-index=0
grub2-editenv: Fehler: Environment-Block ist zu klein.

Aber immerhin gibt es hier den Hinweis, der Block ist zu klein? Wie kann das sein, da steht doch min. der ALTE Kernel auch drin, wie kann der sich nur durch eine Nummer unterscheidene neue Kernel da nicht auch reinpassen?

Weil da wer von Hand rumgefummelt hatte …

Ja, ich gebs zu, ich habe mal irgendwann den Kernel von Hand da eingetragen, aber das war noch zu 4.20er Zeiten und seit dem gings doch auch, sonst wärs ja nicht 5.2.7 geworden. Die mögliche Antwort ist wenig schmeichelhaft: Grubby ist nicht ganz deterministisch veranlagt in letzter Zeit. Ich erwähnte ja, daß sich die Devs und Maintainer schon länger damit rumquälen, mal gehts, mal gehts nicht mehr. Die Bugreporter sind entsprechend genervt. Die Codebasis von Grubby will ich wohl besser nicht sehen.

Egal, eine Lösung muß her

Also, Ursache ist, daß Grubby nur dann das File erzeugt, wenn es GENAU 1024 Bytes lang ist. Keine Ahnung wieso und ich will es auch nicht wissen…. doch will ich, aber werde ich wohl trotzdem nie erfahren.

Sofern nichts außer dem Kernel in dem grubenv File steht, ist der Fix besonders einfach:

wahlweise mit EFI oder ohne :

rm -f /boot/grub2/grubenv
rm -f /boot/efi/EFI/fedora/grubenv

und dann den Block neu erzeugen lassen:

grubby –set-default-index=0

Fixed. Kniffliger wird es, wenn da noch andere Variablen drinstehen, denn dann dürft Ihr ungelogen mit einem Texteditor die Datei auf genau die 1024 Bytes trimmen/padden und dann abspeichern. Danach sollte grubby auch wieder den Default-Kernel da rein schreiben können.

Achtung:

ggf. sind /boot/grub2/grubenv und /boot/efi/EFI/fedora/grubenv  durch einen Symlink verbunden, schaut Euch das bitte vorher von Hand an, bevor Ihr Euch in Sicherheit wiegt. Es ist Eure Bootconfiguration, also lasst Vorsicht walten 😉 Bei Fragen, welche Datei zuständig ist, wendet Euch an die örtliche LUG, die freuen sich über Zulauf 🙂