Tag Archives: kernel

Kernel <= 5.5.9 mit USB Bug

Posted on by

Besonders für alle Fans von  Surface Pro Linux-Tablets habe ich eine schlechte Nachricht im Bezug auf den Kernel 5.5.8: einige USB Geräte werden nur beim Booten erkannt, später aber nicht mehr.

Kernel <= 5.5.9 mit USB Bug

Die Liste der betroffenen Geräte dürfte bislang eher übersichtlich sein, da z.B. meine USB Maus oder mein USB Gigabit LAN Adapter  von dem Problem nicht betroffen sind. Über die Ursache ist bislang auch noch nichts bekannt, was aber nicht verwundert, da wir das erst heute Vormittag verifiziert bekommen haben.

Was ist denn überhaupt los?

Wenn man das Gerät mit Kernel 5.5.x bootet, wird das Microsoft eigene TypeCover, das ist die Tastatur und das Mauspad, welches auch als Deckel dient, korrekt als USB Device erkannt und funktioniert entsprechend. Allerdings nur so lange, bis jemand das TypeCover abzieht und wieder dransteckt. Dann funktioniert es nicht mehr.  Dabei ist es egal aus welcher Quelle man den Kernel hat, ob er direkt von Fedora oder selbst gebaut ist.

Wie wirkt sich das aus?

Die Ursache dafür, daß das TypeCover nach dem Einstecken an das Gerät nicht mehr funktioniert ist, daß es überhaupt nie vom USB BUS abgemeldet wurde. Das manifestiert sich darin, daß man mit „lsusb“ das Gerät noch sieht, auch wenn es bereits am anderen Ende der Wohnung liegt. Folglich wir es beim Einstecken nicht initialisiert und kann so seinen Job nicht tun.

Gegenmaßnahmen

Wie schnell so einn Satz wie „Derzeit hilft nur ein Reboot.“ obsolete wird. Der Einsatz von Kernel 5.5.9-200 (Upstreambuild) oder 5.4.19 bzw. jedes anderen 5.4er Kernel ohne Sicherheitslücke löst das Problem auch, weil es da nicht auftritt. Somit wurde auch indirekt bestätigt, daß es nur am Kernelcode liegt und nicht an der Installation oder irgendwelchen UDEV Tricks, die sind bei allen Kernels gleich, weswegen man die aus der Gleichung streichen kann.

Der Nachteil beim 5.4.x Kernel ist allerdings, daß er zu viel Strom verbraucht. Es wurden im Leerlauf 12 W gemessen, wo mit einem für Surface gebaute Kernel nur ~5 W verbraucht werden. Das sich das echt fies auf die Laufzeit auswirkt, dürfte jedem klar sein.

Die derzeit im Test befindliche 5.5.9-100 von Fedora löst das Problem noch NICHT.

Update ( 11:55 Uhr )

Wie das so mit Eilmeldungen ist, der Patch in 5.5.9-2 ist nicht stabil. Ein einem Boot funktioniert USB wieder, im anderen nicht. Ich halte Euch auf dem Laufenden, wenn ich was neues erfahre.

 

Fedora: Kernel 5.4.7 verfügbar

Posted on by

Mit dem Push vom Linux Kernel 5.4.7 ins stabile Repository von Fedora, hat die Nvidia HDMI Audiokrise ein Ende.

Kernel 5.4.7 verfügbar

Wie in dem Beitrag vom Dezember 2019 „Kernel 5.3.16 mit HDMI-Audio Problemen“ beschrieben, gab es ein ein kleines Problem beim korrekten Markieren von NVIDIA Audiogeräten, z.b. Monitoren mit Lautsprechern. Das wurde nicht mehr für die 5.3er Serie des Kernels behoben, obwohl es nur EIN einziger Zeichenwechsel gewesen wäre.

Wie sich damals ja schnell herausgestellt hat, wollte man mit einem Fix eigentlich ein anderes Problem bei Audiogeräten beheben, hat aber mehr kaputt gemacht, also der Fix behoben hatte. Da so ein Kernelbuild auch auf einem schnellen i7 auf SSDs mal locker 1h plus Tests dauern kann,  kann ich schon verstehen, daß man keine eigene Kernelrelease für den an sich trivialen Fix gebaut hat, zumal man einfach auf einen alten Kernel ausweichen konnte.

Es bleibt zu hoffen, daß es nicht nochmal passiert, denn es hat echt in den Ohren geklingelt.

Grubby: wie man wieder einen Default Kernel setzen kann

Posted on by

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 🙂