Den Linux-Kernel patchen

  Dante Calabresi   Lesezeit: 5 Minuten  🗪 3 Kommentare Auf Mastodon ansehen

Es kann vorkommen, dass der Linux-Kernel der verwendeten Distribution nicht korrekt funktioniert. Auf Arch-Linux lässt sich mit wenig Aufwand ein eigener Kernel mit beliebigen Anpassungen erstellen.

den linux-kernel patchen

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

Tags

kernel, arch, kompilieren, patch

Mattias
Geschrieben von Mattias am 9. Juni 2025 um 12:26

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?

kamome
Geschrieben von kamome am 10. Juni 2025 um 07:13

> 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) …

Dante
Geschrieben von Dante am 10. Juni 2025 um 13:35

> 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