Patches testen
Eine Kurzanleitung zum Testen, ob ein Patch Ihr Problem behebt.
Gelegentlich werden Sie bei dem Versuch, ein Kernel-Problem zu beheben (insbesondere eines, das spezifisch für Ihre Hardware ist), möglicherweise aufgefordert, einen Patch anzuwenden, um zu überprüfen, ob das Problem behoben ist, bevor der Patch eingebunden wird.
Dies ist eine Kurzanleitung, wie Sie den Quellcode des Fedora-Kernels für Ihre Fedora-Version erhalten, den Patch anwenden und einen Kernel zum Testen erstellen. Diese Anleitung richtet sich an Benutzer, die mit dem Fedora-Kernel-Entwicklungsprozess nicht vertraut sind und setzt nur grundlegende Kenntnisse der zugehörigen Werkzeuge voraus.
Einrichtung
Als Erstes müssen Sie, falls noch nicht geschehen, fedpkg (das RPM-Paketbaudienstprogramm von Fedora) installieren:
$ sudo dnf install fedpkg
Als Nächstes beschaffen Sie sich den Quellcode (dadurch wird ein neues Unterverzeichnis „kernel“ erstellt, in dem alle notwendigen Dateien abgelegt werden):
$ fedpkg clone --anonymous kernel
Das Mock-Dienstprogramm wird verwendet, um die Pakete aus den Kernel-Quellen zu erstellen. Auf einem System, auf dem SELinux im Erzwingungsmodus läuft, müssen Sie sicherstellen, dass die Dateikontexte für das Verzeichnis, in dem sich Ihre Kernel-Quellen befinden, korrekt gesetzt sind.
$ sudo semanage fcontext -a -t mock_var_lib_t kernel
$ sudo restorecon -R kernel
Wechseln Sie anschließend in das erstellte Verzeichnis „kernel“:
$ cd kernel
Nachdem Sie das Kernel-Verzeichnis gewechselt haben, müssen Sie mit dem folgenden Befehl zum Zweig für Ihre aktuelle Fedora-Version wechseln, wobei „<Fedora-Version>“ Ihre Fedora-Version ist:
$ fedpkg switch-branch f<Fedora-Version>
Wenn Sie beispielsweise Fedora 44 verwenden, würden Sie Folgendes ausführen:
$ fedpkg switch-branch f44
Zum Schluss müssen Sie sich mit dem folgenden Befehl zur Gruppe „mock“ hinzufügen, wobei „<Benutzername>“ Ihr Fedora-Benutzername ist:
$ usermod -a -G mock <Benutzername>
Damit diese Änderung wirksam wird, können Sie sich entweder ab- und wieder anmelden oder den folgenden Befehl ausführen und dann eine neue Shell-Sitzung oder ein Terminal öffnen:
$ newgrp -
Anwenden des Patches
Um den Patch anzuwenden, speichern Sie die von Ihnen angeforderte .patch-Datei im Verzeichnis „kernel“, das im vorherigen Schritt erstellt wurde, wie folgt:
linux-kernel-test.patch
Build-ID des Kernels setzen
Um Konflikte mit vorhandenen Kernels zu vermeiden, legen Sie eine benutzerdefinierte Build-ID fest, indem Sie die Datei kernel.spec im Verzeichnis „kernel“ bearbeiten.
Suchen Sie die Zeile, die # define buildid .local entspricht, und ändern Sie sie in %define buildid .<Ihre_benutzerdefinierte_ID>.
Beachten Sie, dass <Ihre_benutzerdefinierte_ID> eine numerische Build-ID sein sollte; sie dient dazu, Ihren Kernel-Build von anderen, von Fedora erstellten Kerneln zu unterscheiden, und kann helfen, Konflikte beim Wechsel zwischen Kerneln oder bei der Paketinstallation zu vermeiden.
Sie können sed verwenden, um diese Änderung direkt vorzunehmen, zum Beispiel:
$ sed -i 's/# define buildid .local/%define buildid .1000/' kernel.spec
Pakete bauen
Um die Kernel-Pakete zu erstellen, stellen Sie zunächst sicher, dass Sie sich im Verzeichnis „kernel“ befinden.
Dieser nächste Schritt kann eine Weile dauern, warten Sie daher unbedingt, bis Sie genügend Zeit haben, Ihren Computer arbeiten zu lassen.
Führen Sie anschließend folgenden Befehl aus:
$ fedpkg mockbuild
Gönnen Sie sich zum Schluss ein heißes Getränk, machen Sie einen Spaziergang, spielen Sie mit Ihrem Hund oder entspannen Sie sich auf andere Weise und kommen Sie später wieder.
Installation der Pakete
Um die Pakete zu installieren, stellen Sie zunächst sicher, dass Sie sich im Verzeichnis „kernel“ befinden. Von dort aus wechseln Sie in das Verzeichnis „results_kernel“:
$ cd results_kernel
Dieses Verzeichnis enthält ein einzelnes Unterverzeichnis mit der Kernel-Versionsnummer. Verwenden Sie den Befehl „ls“, um dessen Namen zu ermitteln, zum Beispiel:
$ ls
7.1.3
Wechseln Sie in dieses Verzeichnis:
$ cd 7.1.3
Wiederholen Sie diesen Vorgang noch einmal:
$ ls
201.1000.fc44
$ cd 201.1000.fc44
Wenn Sie schließlich den Befehl „ls“ noch einmal ausführen, sehen Sie eine Reihe von „.rpm“-Dateien. Zum Beispiel:
build.log
hw_info.log
installed_pkgs.log
kernel-7.1.3-201.1000.fc44.x86_64.rpm
kernel-7.1.3-201.1000.fc44.x86_64.rpm
kernel-core-7.1.3-201.1000.fc44.x86_64.rpm
kernel-debug-7.1.3-201.1000.fc44.x86_64.rpm
kernel-debug-core-7.1.3-201.1000.fc44.x86_64.rpm
kernel-debug-debuginfo-7.1.3-201.1000.fc44.x86_64.rpm
kernel-debug-devel-7.1.3-201.1000.fc44.x86_64.rpm
kernel-debug-devel-matched-7.1.3-201.1000.fc44.x86_64.rpm
kernel-debuginfo-7.1.3-201.1000.fc44.x86_64.rpm
kernel-debuginfo-common-x86_64-7.1.3-201.1000.fc44.x86_64.rpm
kernel-debug-modules-7.1.3-201.1000.fc44.x86_64.rpm
kernel-debug-modules-core-7.1.3-201.1000.fc44.x86_64.rpm
kernel-debug-modules-extra-7.1.3-201.1000.fc44.x86_64.rpm
kernel-debug-modules-internal-7.1.3-201.1000.fc44.x86_64.rpm
kernel-debug-uki-virt-7.1.3-201.1000.fc44.x86_64.rpm
kernel-debug-uki-virt-addons-7.1.3-201.1000.fc44.x86_64.rpm
kernel-devel-7.1.3-201.1000.fc44.x86_64.rpm
kernel-devel-matched-7.1.3-201.1000.fc44.x86_64.rpm
kernel-modules-7.1.3-201.1000.fc44.x86_64.rpm
kernel-modules-core-7.1.3-201.1000.fc44.x86_64.rpm
kernel-modules-extra-7.1.3-201.1000.fc44.x86_64.rpm
kernel-modules-extra-matched-7.1.3-201.1000.fc44.x86_64.rpm
kernel-modules-internal-7.1.3-201.1000.fc44.x86_64.rpm
kernel-selftests-internal-7.1.3-201.1000.fc44.x86_64.rpm
kernel-tools-7.1.3-201.1000.fc44.x86_64.rpm
kernel-tools-debuginfo-7.1.3-201.1000.fc44.x86_64.rpm
kernel-tools-libs-7.1.3-201.1000.fc44.x86_64.rpm
kernel-tools-libs-devel-7.1.3-201.1000.fc44.x86_64.rpm
kernel-uki-virt-7.1.3-201.1000.fc44.x86_64.rpm
kernel-uki-virt-addons-7.1.3-201.1000.fc44.x86_64.rpm
libperf-7.1.3-201.1000.fc44.x86_64.rpm
libperf-debuginfo-7.1.3-201.1000.fc44.x86_64.rpm
libperf-devel-7.1.3-201.1000.fc44.x86_64.rpm
perf-7.1.3-201.1000.fc44.x86_64.rpm
perf-debuginfo-7.1.3-201.1000.fc44.x86_64.rpm
python3-kernel-tools-7.1.3-201.1000.fc44.x86_64.rpm
python3-perf-7.1.3-201.1000.fc44.x86_64.rpm
python3-perf-debuginfo-7.1.3-201.1000.fc44.x86_64.rpm
root.log
rtla-7.1.3-201.1000.fc44.x86_64.rpm
rtla-debuginfo-7.1.3-201.1000.fc44.x86_64.rpm
rv-7.1.3-201.1000.fc44.x86_64.rpm
rv-debuginfo-7.1.3-201.1000.fc44.x86_64.rpm
state.log
Erstellen Sie ein Verzeichnis, um die RPM-Dateien zu speichern, die Sie nicht verwenden möchten – wie etwa die .src.rpm- und *devel-Dateien –, und verschieben Sie diese Dateien mit den folgenden Befehlen in das Verzeichnis:
$ mkdir dev
$ mv *.src.rpm dev
$ mv *devel*.rpm dev
$ mv *debug*.rpm dev
Die Liste sollte nun etwa so aussehen:
build.log
dev
hw_info.log
installed_pkgs.log
kernel-7.1.3-201.1000.fc44.x86_64.rpm
kernel-core-7.1.3-201.1000.fc44.x86_64.rpm
kernel-modules-7.1.3-201.1000.fc44.x86_64.rpm
kernel-modules-core-7.1.3-201.1000.fc44.x86_64.rpm
kernel-modules-extra-7.1.3-201.1000.fc44.x86_64.rpm
kernel-modules-extra-matched-7.1.3-201.1000.fc44.x86_64.rpm
kernel-modules-internal-7.1.3-201.1000.fc44.x86_64.rpm
kernel-selftests-internal-7.1.3-201.1000.fc44.x86_64.rpm
kernel-tools-7.1.3-201.1000.fc44.x86_64.rpm
kernel-tools-libs-7.1.3-201.1000.fc44.x86_64.rpm
kernel-uki-virt-7.1.3-201.1000.fc44.x86_64.rpm
kernel-uki-virt-addons-7.1.3-201.1000.fc44.x86_64.rpm
libperf-7.1.3-201.1000.fc44.x86_64.rpm
perf-7.1.3-201.1000.fc44.x86_64.rpm
python3-kernel-tools-7.1.3-201.1000.fc44.x86_64.rpm
python3-perf-7.1.3-201.1000.fc44.x86_64.rpm
root.log
rtla-7.1.3-201.1000.fc44.x86_64.rpm
rv-7.1.3-201.1000.fc44.x86_64.rpm
state.log
Installieren Sie abschließend alle RPM-Pakete in diesem Verzeichnis mit dnf:
$ sudo dnf install ./*.rpm
Testen des Kernels
Sobald alles erfolgreich installiert ist, starten Sie den Computer neu. Der von Ihnen erstellte Kernel sollte beim Systemstart automatisch von GRUB ausgewählt werden. Lassen Sie Ihren Computer einfach hochfahren und prüfen Sie, ob Ihr Problem behoben ist.
Gehen Sie zurück
Wenn Sie die Tests abgeschlossen haben und zum vorherigen Kernel zurückkehren möchten, können Sie den Standard-Kernel in GRUB mithilfe von grubby ändern.
Es ist wichtig, Ihren Test-Kernel zu entfernen, um künftige Konflikte zu vermeiden und eine problemlose Aktualisierung Ihres Systems in der Zukunft zu ermöglichen.
Überprüfen Sie, welche Kernel auf dem System verfügbar sind:
$ sudo grubby --info=ALL
index=0
kernel="/boot/boot/vmlinuz-6.19.10-300.fc44.x86_64"
args="no_timer_check console=tty1 console=ttyS0,115200n8 systemd.firstboot=off rootflags=subvol=root"
root="UUID=15c26993-ac30-424a-9c4b-faec4434d234"
initrd="/boot/boot/initramfs-6.19.10-300.fc44.x86_64.img"
title="Fedora Linux (6.19.10-300.fc44.x86_64) 44 (Cloud Edition)"
id="b208e0c02ac84ca1a2150fc5ec1fa60e-6.19.10-300.fc44.x86_64"
index=1
kernel="/boot/boot/vmlinuz-7.1.3-201.1000.fc44.x86_64"
args="ro rootflags=subvol=root no_timer_check console=tty1 console=ttyS0,115200n8 systemd.firstboot=off rootflags=subvol=root"
root="UUID=15c26993-ac30-424a-9c4b-faec4434d234"
initrd="/boot/boot/initramfs-7.1.3-201.1000.fc44.x86_64.img"
title="Fedora Linux (7.1.3-201.1000.fc44.x86_64) 44 (Cloud Edition)"
id="4d3467c7ecab402cbe8242a1413beb27-7.1.3-201.1000.fc44.x86_64"
Verwenden Sie den Index, um den Kernel zu identifizieren, den Sie als Standard verwenden möchten, und legen Sie ihn wie folgt fest:
$ sudo grubby --set-default-index=0 Der Standard ist /boot/loader/entries/b208e0c02ac84ca1a2150fc5ec1fa60e-6.19.10-300.fc44.x86_64.conf mit dem Index 0 und kernel /boot/boot/vmlinuz-6.19.10-300.fc44.x86_64
Starten Sie das System neu.
Überprüfen Sie, ob das System mit dem gewünschten Kernel läuft:
$ uname -r 6.19.10-300.fc44.x86_64
Wenn der gewünschte Kernel läuft, verwenden Sie den folgenden Befehl, um die Installation des Kernels rückgängig zu machen:
$ sudo dnf history undo last
Anschließend werden Sie aufgefordert, die soeben installierten Kernel-Pakete zu entfernen. Falls weitere Pakete angezeigt werden, verwenden Sie dnf history, um die zu entfernende Transaktion zu finden. Suchen Sie nach der Zahl am Anfang einer Zeile, die die installierte Kernel-Version enthält:
$ dnf history --reverse ... 7 dnf install ./kernel-7.1.3-201.1000.fc44.x86_64.rpm ./kernel-core-7.1.3-201.1000.fc44.x86_64.rpm ...
Diese Nummer „7“ kann dann mit folgendem Befehl rückgängig gemacht werden:
$ sudo dnf history undo 7
Überprüfen Sie, ob der mit dem Patch erstellte Kernel aus GRUB entfernt wurde:
$ sudo grubby --info=ALL index=0 kernel="/boot/boot/vmlinuz-6.19.10-300.fc44.x86_64" args="no_timer_check console=tty1 console=ttyS0,115200n8 systemd.firstboot=off rootflags=subvol=root" root="UUID=15c26993-ac30-424a-9c4b-faec4434d234" initrd="/boot/boot/initramfs-6.19.10-300.fc44.x86_64.img" title="Fedora Linux (6.19.10-300.fc44.x86_64) 44 (Cloud Edition)" id="b208e0c02ac84ca1a2150fc5ec1fa60e-6.19.10-300.fc44.x86_64"
Wenn Sie schließlich einen Neustart durchführen, sollte der neue Kernel (z. B. 7.1.3-201.1000) nicht mehr in GRUB angezeigt werden.
Want to help? Learn how to contribute to Fedora Docs ›