Tag Archives: kernel

Wenn sich Grub und Grubby uneins sind

Posted on by

Ihr erinnert Euch noch an den Artikel Fedora 30&31 Bootumstellung führt zu Startproblem? Davon habe ich eine neue Version für Euch 🙂

Wenn sich Grub und Grubby uneins sind

Allen Anfängern rate ich jetzt mal zunächst ein bisschen zu Lesen: Grubby: wie man wieder einen Default Kernel setzen kann damit dürfte klar sein, was Grubby macht. Grub ist der verbreiteste Bootloader für Linux und der liest normalerweise das ein, was Grubby so von sich geschrieben hat. Wenn ich das schon so flapsig schreibe, dann kann das ja eigentlich schon nicht stimmen, tut es auch nicht immer 🙂

Fangen wir mit der Geschichte von vorn an …ää ähm .. ä ..hm… es war mal im Jahr 2019 ein Fedora Releasewechsel von Fedora 29 auf 30, und ein Linux Tablet. Ok,ok, mein Tablet war zwar an der Geschichte beteiligt, aber das hätte jedem PC passieren können, ehrlich 😉 Mit Fedora 30 wurde ja BLS eingeführt und dabei muß jemand an Grub geschraubt und was falsch gemacht haben, denn bis zu dem Upgrade lief das mit dem Setzen des Default Kernels über Grubby noch.

„Ihr wagt es mir zu trotzen, wer seid Ihr Ritter Rosthülle!“

Seit dem Update konnte ich machen was ich wollte, es wurde immer der erste Kernel in Menü als Bootkernel ausgewählt, egal was ich mit Grubby angestellt habe. Zu beachten ist hier, daß immer alle aktuell installierten Kernels im Menü aufgetaucht sind. Nun habe ich ja für den Beitrag zum neuen Surfacekernel Repo einen, wer würde es erraten, neuen Kernel installiert \o/ und prompt bootete der nicht automatisch. Da ich aber sicher gehen wollte, daß der immer startet, habe ich da nochmal alles überprüft.

Die Dateien in /boot/grub2/ waren alle OK. Wenn Grubby gehustet hat, änderten sich die grubenv und die grub.cfg untertänigst und trotzdem blieb es beim ersten Kernel im Menü. Unglaublich. Jetzt kann man glücklicherweise im Grubmenü auf „c“ drücken und kommt in die GrubShell. Wenn man da „set“ aufruft, zeigt er einem die Grubvariablen an, das sind die, die man mit dem Eintrag in der grubenv überschreiben kann. Wenn man sich die grub.cfg ansieht:

if [ -f ${config_directory}/grubenv ]; then
    load_env -f ${config_directory}/grubenv
elif [ -s $prefix/grubenv ]; then
    load_env
fi

erkennt man auch als Uneingeweihter, daß hier die grubenv geladen werden soll. d.b. Schritt Eins vom Bootloader, bevor das Menü überhaupt zusammenbaut wird, ist also die grubenv laden und die passenden Variablen setzen oder überschreiben.

Die GrubShell

Wie bereits erwähnt kann man sich das Ergebnis in der GrubShell ansehen, wenn man „set“ eingibt. Solltet Ihr beim nächsten Boot einfach mal machen und reinsehen. „boot“ oder „reboot“ bringen Euch da wieder raus. Als ich heute (für Euch vor 2 Wochen) in die Variablenliste von „set“ sah, wäre ich fast vom Stuhl gefallen. Da stand allen ernstes ein Kernel 5.2.7 (Fedora 29) als Defaultkernel drin! Den gab es unter /boot/ aber gar nicht mehr und das System hat nur eine Bootplatte. Ich habe ja erwähnt, daß alle Kernel, die hätten im Menü sein sollen, auch im Menü drin waren. Ein Kernel 5.2.7 wäre da aufgefallen.

Jetzt sucht mal auf der Platte nach einem Kernel, den es seit 5 Monaten nicht mehr gibt, viel Spaß dabei! Das muß ja irgendwo drin stehen, also /etc/ durchsucht, /boot/grub2 durchsucht, /usr/ durchsucht, nichts! Kein Kernel, kein Eintrag.. wo zum Geier kommt das her? Grubby schreibt doch jede Änderung des Kernels direkt in die Files, da KANN DOCH GAR KEIN ALTER KERNEL DRINSTEHEN!

Wenn A und B nicht das Gleiche sind!

Stands auch nicht. Die Lösung für das Problem war dann weniger spannend als die Suche danach 🙂 Grubby änderte die Dateien in /boot/grub2, aber Grub lud nicht /boot/grub2 sondern /boot/EFI/efi/fedora/ und da standen uralte Fedora 29 Sachen in den Dateien. Das ist so eine „Links weiß nicht was Rechts tun“ Geschichte. Die Lösung für das Problem ist dann ganz einfach, man nimmt einfach zwei Symbolische Links und verknüpft die beiden Orte, so daß es nur noch eine Datei mit dem Inhalt gibt, und nicht mehr zwei verschiedene.

Da Grubby alle aktuellen Anpassungen nach /boot/grub2/ schreibt, aber Grub aus /boot/EFI/efi/fedora/ liest und zu allem Überfluß /boot/ zu „/“ wird, wenn man der Bootloader ist, muß man ein klein bisschen kreativ werden, um den korrekt Pfad für den Link abzuleiten. Folgende Anweisungen können das für Euch direkt lösen:

mv /boot/grub2/grubenv /boot/EFI/efi/fedora/grubenv
mv /boot/grub2/grub.cfg /boot/EFI/efi/fedora/grub.cfg
cd /boot/grub2
ln -s ../EFI/efi/fedora/grubenv
ln -s ../EFI/efi/fedora/grub.cfg

Kurz erklärt

„mv“ steht für „move“ und verschiebt Dateien von A nach B. Wenn B vorhanden, wird es überschrieben, man muß B also nicht vorher löschen.
„ln -s {Pfad/Dateiname}“  legt den symbolischen (-s) Link von {Pfad/Dateiname} als „Dateiname“ im Filesystem an. Sollen Ziel und Quelle des Links gleich heißen muß man da nichts weiter angeben. Üblich wäre aber z.B. „ln -s pfad1/datei1 pfad2/datei2“ . In den Anweisungen oben haben wir einen relativen Pfad ../EFI/efi/fedora benutzt, weil /boot/EFI/efi/fedora nicht geht, da es /boot/ in der Bootparition nicht gibt, denn die wird während des Bootens erst später unter /boot/ eingehängt. Der Bootloader hantiert also direkt im /boot/ rum, weswegen in seinem Kontext „/boot/“ = „/“ ist. Das Root = / ist hätte man riskieren können, aber da Grub nicht von /boot/grub2 lädt, könnte da ja noch viel mehr anders sein, als mir jetzt bekannt ist. Daher war der relative Link hier sicherer als „ln -s /EFI/efi/fedora/grubenv“ zu benutzen.

Für Anfänger: Ein symbolischer Link ist eigentlich nur eine kleine Textdatei, wo das Ziel ( hier ../EFI/efi/fedora/grubenv ) drinsteht. Das Filesystem merkt das, und folgt dann dem Pfad zum eigentlichen Ziel. Symbolische Links kann man quer über alle eingehängten Partitionen benutzen. „Hardlinks“, die sich hier auch angeboten hätten, kann man nur innerhalb einer Partition benutzen, dafür haben die andere Vorteile.

Bugreport ist raus, mal sehen wann die Beule am Kopf der GrubDevs vom gegen die Wand schlagen wieder abgeschwollen ist 🙂

Linux: Surface Tablets und Laptops mit eigenem Kernel-Repo

Posted on by

„Du saga mal, Du hascht doch des Suuhrfaze, gibtsch da scho wos njeues pführ?“ hallte es aus dem mitfünfziger Herrn am Tisch gegenüber. Freundlich, aber bestimmt, machte Ihm mein Sitznachbar darauf aufmerksam, daß er kurz hinter Kiel wäre und folglich kaum zu verstehen sei. Dies schien den Herrn genauso wenig zu stören, wie der Umstand, daß mein Sitznachbar eher andigital veranlagt ist und es sich bei dem Gerät vielmehr um eine kurz Präsentationsleihgabe meinerseits handelte.

Nachdem die beiden Fischköpfe ( wir… vermutlich ) kurz getuschelt hatten, übersetzte eine junge Dame (Bezeichnung Anna-Luisa o7) für uns (daher auch die grobe Entschlüsselung oben) und es entstand eine schöne , wenn auch sehr kurze, Unterhaltung zum Thema: Linux auf einem Surface Pro 4.

Surface Tablets und Laptops mit eigenem Kernel-Repo

„Ja, da gibts was njeues.. ehm.. neues“ und für Euch schalte ich das Gespräch mal auf Allwissenden Erzähler um, sonst darf ich mich in Bayern gar nimmer sehen lassen. Also, Ja Leute, es gibt eine nicht mehr ganz taufrische Entwicklung, die teils sehr erfreulich, weil unheimlich praktisch ist, andererseits leider nicht so ganz funktioniert. Letzterer Teil wird derzeit noch untersucht.

Seit einige Monaten gibt es im Github einen eigenen Prebuild-Kernel für Arch, Debian und Fedora. Den richtet Ihr Euch so für Fedora ein:

  1. Das Repo hinzufügen:

sudo dnf config-manager --add-repo=https://pkg.surfacelinux.com/fedora/linux-surface.repo

2. Den Kernel  installieren:

sudo dnf install kernel-surface surface-firmware surface-secureboot
sudo dnf install --allowerasing libwacom-surface

3. Letztere Anweisung ist eher optional, falls man mit Wacom Probleme hat., was auch die Stifteingabe betrifft.

Surface rebooten, den neuen Kernel auswählen und jetzt kommt es drauf an, ob Ihr ein SP4/SB1 habt oder ein anderes Surfacegerät Euer eigen nennt, denn bei mir (SP4) bootet der Kernel zwar sauber, aber IPTS ist nicht da, was man allerdings für Touchbedienung braucht.  So bin ich kaum einen Schritt weiter als mit dem Kernel von Fedora selbst. Ein Problem an dem derzeit gearbeitet wird.

Und da ist auch schon die Lösung … ( sowas von genial den Artikel schon Tage im Voraus zu schreiben 😀 ) … dem mangelnden Touchsupport kann man so begegnen:

[root@surface]# rmmod ipts
[root@surface]# insmod /lib/modules/5.5.8-1.surface.fc30.x86_64/kernel/drivers/input/touchscreen/ipts/ipts.ko.xz singletouch=y

Was man dann so verewigt:

echo „options ipts singletouch=y“ > /etc/modprobe.d/ipts.conf

Man muß aber wissen, das dann der Stiftsupport abgeschaltet ist. Außerdem ist im 5.5er Kernel die Multitouch-Support komischerweise abgeschaltet, wer das braucht, muß den LTS Kernel 4.19 installieren. Ob das bei einem aktuellen Fedora 30/31/32 eine gute Idee ist, mag ich nicht entscheiden wollen. Allerdings hatte der 5.3er noch Multitouch dabei. Da frage ich mich jetzt, wieso das abgeschaltet wurde.

Weniger Energieverbrauch .. vielleicht

Eine andere Sache, die noch untersucht werden muß, ist der anscheinend geringere Stromverbrauch des 5.5.8 Kernels auf dem Surface Pro 4. zunächst sah es eher nach einem Batteryauslesebug aus, weil das Gerät lange auf 100% blieb, aber mittlerweile könnnte auch ein leichter Einspareffekt vorhanden sein. Ich hab das SP4 noch nicht lange genug im Referenzkernel laufen lassen, um da einen Vergleich zu haben. Ich schau nachher mal.

Kameras gehen immer noch nicht

Tja, schlechte Nachrichten für die NSA, die Kameras der Surface Pro 4+ funktionieren immer noch nicht unter Linux, was an sich jetzt schade für reguläre Kameranutzer ist. Dafür soll das Wifi jetzt im 5G Betrieb stabiler sein, was ja auch nicht ganz unpraktisch ist.

Die Sache mit dem Secure Boot

Nachdem ersten Boot, kommt im Bootprozess eine mördermäßig wichtige Einblendung, die einem bei der Installation auch mitgeteilt wird, allerdings steht im Installationshinweis, daß man, WENN MAN danach gefragt wird, ein Password eingeben soll um den signierten Kernel, bzw. dessen Signatur, ins Bios zu bekommen um dann Secure Boot nutzen können. Tja, was soll ich sagen, die Abfrage kam so nicht, denn dazu muß man während ein Timer runterzählt auf eine Taste drücken, sonst wird man auch nicht nach dem Passwort gefragt 🙂

Da ich da noch unsignierte Kernels zum Testen liegen habe, kann ich SecureBoot eh nicht einschalten, insofern ist mir das auch egal 😉 Wenn der neue Kernel natürlich dauerhaft funktioniert, dann kann man das später immer noch mit Hilfe des mokutil erledigen.

Der TypeCover Bug

Zwar prellt das TypeCover nicht mehr, aber dafür funktioniert es auch nicht mehr, wenn man es abzieht und wieder dran steckt. Was ein Problem darstellt, da man das Surface Pro 4 neu booten muß.

Ihr seht, da werden noch einige Fixe nötig werden, bis das stabil läuft.

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.