Das Problem
Ich bin grundsätzlich immernoch sehr zufrieden mit meinem Arbeitsgerät auf Linuxbasis. Allerdings trat bereits seit längerer Zeit ein sehr mühsamer Bug auf, welcher verhinderte, dass sich meine Bluetooth-Maus mit dem Tablet verbinden konnte. Da das Touchpad des Starlite nicht das Beste ist, war dies eine deutliche Komforteinbusse.
Eine kurze Problemsuche brachte den Fehler mit dem Upgrade auf den Linux-Kernel 6.11 in Verbindung. Als vorläufige Lösung fixierte ich somit den Kernel auf dem letzten funktionierenden Stand in Version 6.10.10 und wartete auf einen Fix im Kernel oder der Firmware des Geräts.
Die Monate vergingen und ich testete in der Hoffnung auf einen Fix brav die neuen Kernel-Versionen, jedoch stets erfolglos. Aufploppende CVEs im Kernel bereiteten mir immer stärkeres Unbehagen.
Die Lösung
Nach einer neuerlichen Recherchetour durch Foren und Issue-Tracker stiess ich dann auf die Ursache des Bugs. Anscheinend wurde im Bluetooth-Stack des Kernels eine (sinnvolle) Änderung eingefügt, welche zum Problem auf dem Starlite führte. Da das Problem auch nach Monaten bislang nicht behoben war, schien es auch nicht so einfach zu lösen.
Der Finder des Bugs stellte grosszügigerweise jedoch ein Patch-File zur Verfügung, welches das Problem vorerst umgehen sollte. Die Herausforderung war jedoch, dass der Linux-Kernel selbst gepatcht werden musste, was ich mir bis jetzt bisher nicht zugetraut hatte.
Glücklicherweise stellte sich die Arch-Wiki (wieder einmal) als grossartige Quelle von Wissen und Hinweisen heraus.
Der Artikel zum Kernel im Arch Build System ist sehr detailliert und enthält alle nötigen Informationen. Im Folgenden werde ich die für mich relevanten Schritte aufzeigen.
Linux-Paket anpassen
Um einen eigenen Kernel zu kompilieren, wird ein neues Arch-Paket zusammengestellt, welches auf dem bestehenden linux-Paket des Arch-Repository aufbaut.
Dazu sind zwei Arch-Pakete notwendig, welche bei mir nicht standardmässig installiert waren:
sudo pacman -S devtools base-devel
Man erstellt einen Ordner für die Paketkonfiguration und den Sourcecode:
mkdir ~/build/
cd ~/build/
Danach kopiert man die bestehende Arch-Paket-Anleitung:
pkgctl repo clone --protocol=https linux
cd linux
Nun editiert man die Datei PKGBUILD
. Dabei ändert man den Namen, damit das Paket parallel zum bestehenden Kernel installiert werden kann.
pkgbase=linux-custom
Zusätzlich entfernt man die Dokumentation aus dem Paket, welche hier nicht benötigt wird. Zum einen lässt sich alles unterhalb von #htmldocs
im Abschnitt makedepends=()
entfernen. Auch kann make htmldocs
in build()
entfernt werden, sowie "$pkgbase-docs"
in pkgname
.
Nun kopiert man den gewünschten Patch ins Verzeichnis ~/build/Linux/src/
.
Laut Arch-Wiki sollten alle .patch
Dateien im src/
-Verzeichnis automatisch angewendet werden. Bei mir hat das jedoch nicht geklappt und ich musste die prepare()
-Funktion in PKGBUILD
noch um folgende Zeile ergänzen.
patch -Np1 < "../0002-Bluetooth-btintel-don-t-reclassify-signal-for-GfP2-a.patch"
Kernel Kompilieren und Paket schnüren
Nun ist alles bereit für das Kompilieren des Pakets mit makepkg. Um die Kompilierung zu beschleunigen, lohnt es sich, mehrere Kerne zu verwenden. Bei mir wurde per Default nur einer genutzt. Dazu ändert man in
/etc/makepkg.conf
den folgenden Parameter auf die gewünschte Anzahl Kerne.
MAKEFLAGS="-j2"
Danach startet man die Kompilierung des Kernels und das Erstellen des Pakets.
time makepkg -s --skippgpcheck
Der Zusatz time
erlaubt einen Hinweis, wie viel Zeit nötig war und was für zukünftige Updates eingerechnet werden muss. Auf dem Starlite mit dem sehr schmalbrüstigen Intel N200 hat das Kompilieren auf 2 Kernen 3 Stunden gedauert.
--skippgpcheck
verhindert das Prüfen des Sourcecode, da ich Probleme mit dem eigenen Patch-File verhindern wollte.
Es lohnt sich, zu Beginn den Output im Terminal zu beobachten und zu prüfen, dass der Patch tatsächlich angewendet wurde. Ansonsten wird viel Kompilierzeit aufgewendet für nichts.
Pakete installieren
Nach dem Kompilieren müssen die zwei erstellten Pakete noch installiert werden.
ACHTUNG
Ab jetzt würde ich empfehlen, einen funktionierenden USB-Stick mit einem Live-System zur Hand zu haben, um notfalls das System zu reparieren. Es könnte vorkommen, dass der selbst gebaute Kernel nicht korrekt startet und im schlimmsten Fall das System nicht mehr gebootet werden kann.
Die zwei Pakete sollten gleichzeitig via pacman
installiert werden:
sudo pacman -U linux-custom-6.14.9.arch1-1-x86_64.pkg.tar.zst linux-custom-headers-6.14.9.arch1-1-x86_64.pkg.tar.zst
Dadurch werden auch die post-transaction hooks von pacman
ausgelöst, welche den Kernel auf die EFI-Partition kopieren z. B. als /boot/vmlinuz-linux-custom
. Zudem werden auch alle Parameter aus /etc/kernel/cmdline
an den Kernel übergeben. Allfällige eigene Anpassungen werden somit direkt übernommen.
Je nach Bootloader ist der Kernel nun bereits verfügbar. Bei meinem systemd-boot war dies jedoch nicht der Fall.
Kernel für systemd-boot installieren
Bei systemd-boot lassen sich vorhandene Kernel auf der ESP relativ einfach mit kernel-install
hinzufügen.
sudo kernel-install -v add linux-custom-6.14.9.arch1-1 /boot/vmlinuz-linux-custom
Ob es geklappt hat, lässt sich mit bootctl
prüfen, womit auch gleich die ID des neu installierten Kernel ersichtlich wird.
bootctl list
Nun lässt sich der Computer neustarten und der Kernel kann im Boot-Menu ausgewählt werden.
Falls alles wie gewohnt funktioniert (bei mir wurde die Bluetooth-Maus nun ENDLICH wieder erkannt), lässt sich der Kernel als Default beim Booten festlegen, wobei die ID mit bootctl list
bestimmt werden kann.
sudo bootctl set-default ID
Geschafft
Den Linux-Kernel selbst zu verändern und zu kompilieren fühlt sich nach einer Form von Ermächtigung an, welche mir so in der FOSS-Welt nur selten begegnet ist.
Das Herz des eigenen Betriebssystems nach den eigenen Bedürfnissen anzupassen, demonstriert die 4 Freiheiten sehr eindrücklich.
Ich war jedoch überrascht, wie simple des ganze mit aktuellen Werkzeugen von Arch-Linux inzwischen ist.
Damit wurde mir erneut bewusst, wie unglaublich nützlich und wertvoll die Ressourcen der FOSS-Community für die Gesellschafft sind (hier insbesondere der Arch-Community).
Quellen
https://github.com/StarLabsLtd/firmware/issues/180
https://wiki.archlinux.org/title/Kernel/Arch_build_system
https://wiki.archlinux.org/title/Makepkg
https://www.gnu.org/philosophy/free-sw.en.html#four-freedoms
Titelbild generiert mit Le Chat von mistral.ai
Quellen:
https://github.com/StarLabsLtd/firmware/issues/180
https://wiki.archlinux.org/title/Kernel/Arch_build_system
https://wiki.archlinux.org/title/Makepkg
https://www.gnu.org/philosophy/free-sw.en.html#four-freedoms
Titelbild generiert mit _Le Chat_ von mistral.ai
An einer Stelle steht es sei "eine sinnvolle Änderung am Bluetooth-Stack" gewesen. Ist das tatsächlich ein Bug im Kernel oder nicht vielmehr ein Treiber/Firmware-Problem? Einige Logitech Mäuse sind wohl auch betroffen. Etwa genau so lange wie das Problem besteht, ist die Lösung seit 1 Jahr bekannt und dennoch wurde das immer noch nicht gefixed. Gibt es bestimmte Gründe, weiß man wieso das so lange dauert?
Die die hier gezeigte Vorgehensweise ist spezifisch für Arch-basierte Distros, gibt es theoretisch etwas vergleichbares das auch unter Debian, Fedora etc. funktionieren würde?
> gibt es theoretisch etwas vergleichbares das auch unter Debian
https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s-common-official Sollte in die richtige Richtung gehen (nicht getestet) …
> Ist das tatsächlich ein Bug im Kernel oder nicht vielmehr ein Treiber/Firmware-Problem? Die Treiber liegen meines Wissens bei Linux direkt im Kernel, weswegen Hardwareprobleme auch oft dort behoben werden müssen.
Die technischen Details durchschaue ich auch nicht komplett, aber es scheint etwas vertrackt zu sein, so dass man weder vor noch zurück kann. Die "Lösung" ist insofern keine Allgemeine, da andere Hardware dadurch möglicherweise nicht sauber funktioniert.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2100565/comments/25