Grubby: wie man wieder einen Default Kernel setzen kann

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 🙂

Fedora 31: keine i686 Kernels mehr?

Die Schlacht um i686 geht in die nächste Runde, kaum das Ubuntu zurück gerudert hat bzw. sich da noch windet, schlagen die ersten bei Fedora in die gleiche Kerbe: Keine i686 Kernels mehr.

Keine i686er Kernels mehr für Fedora 31+

Ben Cotton hat dazu geschrieben:

On Fri, 21 Jun 2019 at 14:15, Ben Cotton <bcotton@redhat.com> wrote:

https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels

== Summary ==
Stop building i686 kernels, reduce the i686 package to a kernel-headers package that can be used to build 32bit versions of everything else.

Anders als bei Ubuntu sollen alle Supportpakete weiterhin gebaut werden, so daß Wine keine Probleme machen würde, man könnte halt nur keine 32Bit Systeme mehr mit einem neuen Kernel booten und dann in Folge irgendwann gar nicht mehr, weil der Kernel zu dem ganzen Boot/Init des Systems ja in nicht unerheblichen Teilen beiträgt.

Früher oder später war der Schritt ja zu erwarten. Das wenigsten die 32Bit RPMs weiterhin gebaut werden, damit 32 Bit Anwendungen auch unter 64 Bit  funktionieren, ist ein Lichtblick, außer für Besitzer von 32 Bit Systemen.
Ein Wine ohne 32 Bit wäre für viele User ein absolutes No-Go, weil zig alte Windowsgames auf 32 Bit laufen!

Zu viel Drama um die TCP SACK Problematik

Um dem Drama mal den Schwung aus den Segeln zu nehmen:

sudo echo „0“ > /proc/sys/net/ipv4/tcp_sack

auf den gefixten Linux Kernel warten, rebooten, fertig. Wer keinen neueren Kernel bekommt, trotzdem rebooten muß, der fügt :

net.ipv4.tcp_sack = 0

ans Ende der Datei /etc/sysctl.conf an und schon wird SACK beim Start deaktiviert.

Ich könnte natürlich jetzt auch son Quatsch von mir geben wie :

„Ooohhh! Große Lücke im Kernel! Linux Server werden durch DDOS vom Netz genommen! Panik! Ich sagte PANIK! P.A.N.I.K!!!

blöderweise passierte … rein gar nichts davon 😀

Das jeder seinen Krempel mittlerweile nur noch über den Panikbutton vermarktet, macht es echten Lücken, wie der Exim Root-Exploit Geschichte neulich nicht einfacher. Oder dem Firefox Exploit über Javascript! Was fürn Geheul, und ooooooohhh … zwei Tage später der nächste Security Patch… auch wieder alle im Panikmodus. NOSCRIPT installieren und schon ist Ruhe!

Redhat hat 2 Tage gebraucht den FireFox 67.0.3 zu kompilieren, bevor es endlich mal durchlief und ? Juckt das NOSCRIPT User? Nein 🙂

PS: Wer es für Fedora eilig hat mit dem FF Update : https://koji.fedoraproject.org/koji/buildinfo?buildID=1291078

 

Runes of Magic, Linux und der Performance Bug

Ihr könnte Euch gaaaaaaaaaaaaaaanz sicher an die Intel CPU Bugs erinnern und wie die im Linux Kernel abgewehrt wurden, so in etwa. Der Nebeneffekt war, u.a., daß bspw. Runes of Magic als WineApp mit DX9 Teil auf meinem  Achtkerner von im Durchschnitt 150% CPU Last pro Instanz auf 250% hochgeschnellt war. Die Kernels 4.19.9+ > 4.20.latest waren allesamt davon betroffen.

66% mehr CPU Last

Das Phänomen war besonders nervig, weil zwar im Regelbetrieb nur eine leichte Erhöhung von 150% auf 180% vorhanden war, aber sporadisch brach die Lasthölle los, mit den erwähnten Peeks auf 250%, die dann für einige Minuten blieben um dann wieder zu verschwinden. Ein Spielen war so natürlich nicht mehr mit mehreren Instanzen möglich.

Seit Kernel 5.0.6 und vermutlich auch eher, ist die Last wieder zurück auf den Normalwert von 150% im normalen Spielbetrieb. Die Reaktion vom Kernel bzw. Wine Maintainer auf diesen Bugreport war übrigens „Damit können wir nichts anfangen“ mit anderen Worten, sie konnten nicht mal glauben, daß es den Effekt überhaupt gab.

top – 13:11:29 up 1 day, 3:52, 1 user, load average: 4,09, 4,31, 4,87
PID   USER   PR NI VIRT   RES    SHR   S %CPU %MEM TIME+ COMMAND
3542  marius 20 0 2240024 1,238g 76976 S 155,8 7,9 1159:15 H:\Programme\GameforgeLive\Games\DEU_deu\Runes Of Magic\Client.exe NoCheckVersion20398 marius 20 0 2378776 1,291g 78152 R 142,2 8,3 1369:03 H:\Programme\GameforgeLive\Games\DEU_deu\Runes Of Magic\Client.exe NoCheckVersion

Da die Last seit einiger Zeit wieder konstant im grünen Bereich ist, kann man das Problem wohl als gelöst betrachten. Falls jemand von Euch mit einem Programm unter Linux ähnliche Erfahrungen gemacht hat oder derzeit macht, wisst Ihr was die Lösung ist => Kernel Updaten.

Bevor Klagen von Lesern reinkommen: klar hatte ich überprüft, ob sich Wine oder die Grafikkartentreiber geändert hatten, hatten sie nicht.

XenServer zu alt um Kernel 5.0 zu laden

Wer XenServer und Kernel 5.0.x einsetzen will, sollte jetzt gut aufpassen, sonst => VM Streik

Kernelimage zu neu für XenServer 6.2.x

Da es sich um etwas handelt, daß international wichtig sein könnte, gibts das auf Deutsch und English,
so don’t wonder if you just understand halve of it 😉

Ihr wollt Eure VM booten, bekommt aber diesen Fehler?
You wanne boot your VM and get this message ?

xenopsd internal error: XenguestHelper.Xenctrl_dom_linux_build_failure(2, “ panic: xc_dom_core.c:616: xc_dom_find_loader: no loader\\\““)

Das passiert, weil das Kernelimage mit einer neuen Compressionmethode gepackt wurde, die das alte XEN nicht kann.  The reason is, that your kernel image file is compressed with a new algorithm, your old XEN can’t handle.

Als erstes brauchen wir die UUID der VM:
First, get the UUID of your VM:

xe vm-list | grep -A5 -B5 <vmname>

Um das zu beheben, braucht man den Befehl: xe-edit-bootloader.sh -u uuid
To fix your vm, you need to execute : xe-edit-bootloader.sh -u uuid

/root/xe-edit-bootloader.patched.sh -u 317fb132-283a-56c6-1627-8b39cf944148 -p 1

Nun kann man die Reihenfolge der Bootmenüeinträge so ändern, daß der bisherige Kernel vorn steht. Dann speichern und Editor beenden und jetzt sollte die VM auch wieder starten.
Now you can change the order of your grub menuentries to the last working kernel being first. When you have saved and exited the editor, the parition will be unmounted and you can start your VM again.

Tipps – Additional hints for you

Der Befehl mountet die Systemplatte der VM und lädt die gebräuchliste grub.conf. Das wird aber vermutlich nicht auf anhieb klappen. Man muß etwas über das Festplattenlayout der VM wissen:
This will mount your VM’s main disk and access the most likely location of your grub.conf, but that will not work without your knowlage of the VMs structure:

-p: Partition number to mount (default: none)
-f: Location of bootloader config file to edit

Wenn man eine traditionelle SDA1 SDA2 Partitionierung in der VM hat, dann gibt man -p die Partitionsnummer der Platte an, wo man /boot/ finden kann. Wer LVM in der VM benutzt, dürfte jetzt so ziemlich am Arsch sein. Kleiner Tip, exportiert die VM auf einen neuern XenServer.

If you have a sda1 and sda2, where sda2 is swap, that -p 1 will mount partition 1 and your good to go.
If you have i.e. a seperate boot partition, you need to know it’s number.
IN CASE you have LVM inside your VM, i guess your screwed now. In this case, export it to a newer XenServer Version.

Weil sich Grub1+2 ein bisschen uneinig wegen der Verzeichnispfade sind, kann man Position der grub.cfg mit -f angeben. Wer eine eigene /boot Partition hat, braucht dann nicht /boot/ hinschreiben, -f grub2/grub.cfg reicht.

Grub1+2 differ a bit, where to find the grub.conf file. Thats where -f will be handy. You can just tell it, if you knew it: -f /boot/grub2/grub.cfg   should usally work, except, you are already on /boot (seperate partition) then it’s just -f grub2/grub.cfg .  As theres only a texteditor loaded, you could try to change other files too 😉

Ich habe einen gepatchten xe-edit-bootloader, der mir erlaubt, gleich die ganze Platte in Dom0 zu mounten. d.h. ich kann alles in der VM anpassen, nicht nur Textdateien, was extrem praktisch ist.
Why is my xe-edit-bootloader.sh  patched? because i adapted it to just mount the disk and wait for me to explore the disk. That’s so helpfull, you won’t believe it.

Bei einigen Systemen kann durch setzen der $EDITOR Variablen auf „/bin/bash“ eine Shell bekommen, aber ich rate davon ab, daß auf Produktivsystemen auszuprobieren, das könnte böse Nebenwirkungen haben.
In rare cases it’s possible to trick the script with the $EDITOR variable set to „/bin/bash“ to open a bash shell for you, but i really suggest not to mess with your dom0 on a production system.