Einen benutzerdefinierten Kernel bauen

John Soros, Alessio, Brandon Nielsen Version unspecified Last review: 2023-12-23
Dieses Dokument enthält Anweisungen für fortgeschrittene Benutzer, die den Kernel aus den Quellen neu erstellen möchten.

Beim Erstellen oder Ausführen eines benutzerdefinierten Kernels sollte man keine Unterstützung vom Fedora-Kernel-Team erwarten.

Häufige Gründe für die Erstellung eines benutzerdefinierten Kernels sind:

  • Um Patches für Tests anzuwenden, die sie entweder selbst generiert oder aus einer anderen Quelle bezogen haben

  • Um den bestehenden Kernel neu zu konfigurieren

  • Um mehr über den Kernel und die Kernelentwicklung zu erfahren

Abhängigkeiten holen

Die einfachste Methode, alle Bauabhängigkeiten für den Kernel zu installieren, ist die Verwendung der .spec-Datei des Fedora-Kernels:

sudo dnf install fedpkg
fedpkg clone -a kernel
cd kernel
sudo dnf builddep kernel.spec

Wenn Sie make xconfig verwenden möchten, benötigen Sie einige zusätzliche Pakete:

sudo dnf install qt3-devel libXi-devel gcc-c++

Secure boot

Stellen Sie sicher, dass Sie den Benutzer, der den Bau durchführt, zu /etc/pesign/users hinzufügen und das Skript zur Benutzerautorisierung ausführen:

sudo /usr/libexec/pesign/pesign-authorize

Erstellen Sie einen neuen Maschinenbesitzerschlüssel (MOK) zum Importieren in UEFI:

openssl req -new -x509 -newkey rsa:2048 -keyout "key.pem" \
        -outform DER -out "cert.der" -nodes -days 36500 \
        -subj "/CN=<your name>/"

Importieren Sie das neue Zertifikat in Ihre UEFI-Datenbank:

Sie werden beim nächsten Systemstart aufgefordert, den Import zu autorisieren.
mokutil --import "cert.der"

Erstellen Sie eine PKCS #12-Schlüsseldatei:

openssl pkcs12 -export -out key.p12 -inkey key.pem -in cert.der

Anschließend können Sie das Zertifikat und den Schlüssel in die NSS-Datenbank importieren:

certutil -A -i cert.der -n "<MOK-Zertifikat-Nickname>" -d /etc/pki/pesign/ -t "Pu,Pu,Pu"
pk12util -i key.p12 -d /etc/pki/pesign

Sobald Zertifikat und Schlüssel in Ihre NSS-Datenbank importiert wurden, können Sie den Kernel mit dem ausgewählten Schlüssel erstellen, indem Sie %define pe_signing_cert <MOK-Zertifikat-Nickname> zur kernel.spec-Datei hinzufügen oder rpmbuild direkt mit dem Flag --define "pe_signing_cert <MOK-Zertifikat-Nickname>" aufrufen.

Solange der Bugreport #1651020 noch offen ist, müssen Sie möglicherweise die Zeile, die mit %pesign in der Kernel-Spec-Datei beginnt, bearbeiten und durch pesign -c %{pe_signing_cert} --certdir /etc/pki/pesign/ -s -i $KernelImage -o vmlinuz.signed ersetzen.

Es wird außerdem empfohlen, ccache zu installieren, da dies die Geschwindigkeit von Neuerstellungen erhöhen kann:

sudo dnf install ccache

Erstellen eines Kernels aus dem Fedora dist-git

Zunächst ist ein Checkout aus dem Fedora kernel dist-git erforderlich:

git clone https://src.fedoraproject.org/rpms/kernel.git

Der Kernel hat, wie jedes andere Fedora-Paket, für jede Fedora-Version einen eigenen Zweig. rawhide entspricht Rawhide, und jede Fedora-Version hat einen Zweig namens f<Version>.

  1. Um beispielsweise einen Fedora-28-Kernel zu erstellen, müssten Sie zunächst mit folgendem Befehl in den entsprechenden Zweig wechseln:

    git switch f28
  2. Um Konflikte mit bestehenden Kerneln zu vermeiden, können Sie eine benutzerdefinierte Build-ID festlegen, indem Sie # define buildid .local in %define buildid .<your_custom_id_here> in kernel.spec ändern.

  3. Nehmen Sie alle erforderlichen Änderungen oder Anpassungen vor:

    1. Die Kernel-Konfigurationsoptionen können durch Modifizieren der Datei kernel-local überschrieben werden.

    2. Vorhandene Patches können zu linux-kernel-test.patch hinzugefügt werden; sie werden während des Bauprozesses automatisch erkannt.

    3. Patches können auch in separaten Dateien gespeichert und mit Patch2: foo.patch, Patch3: bar.patch usw. zu kernel.spec hinzugefügt werden. Um die Patches während des Bauprozesses anzuwenden, müssen entsprechende Zeilen wie ApplyOptionalPatch foo.patch, ApplyOptionalPatch bar.patch hinzugefügt werden.

    4. Um eigene Änderungen am Kernel-Quellcode vorzunehmen, laden Sie die Kernel-Quellen für Ihren aktuellen dist-git-Branch mit fedpkg sources herunter. Nehmen Sie anschließend die gewünschten Änderungen am Kernel-Quellcode vor und generieren Sie einen Patch, z. B. mit diff -rupN kernel_src_folder kernel_src_folder_patched > mypatch.patch. Der Patch kann dann zu linux-kernel-test.patch oder der Spec-Datei hinzugefügt werden.

  4. Bauen Sie die RPMs:

    fedpkg local
  5. Den neuen Kernel installieren:

    sudo dnf install --nogpgcheck ./x86_64/kernel-$version.rpm

Bau eines Vanilla-Upstream-Kernels

Manchmal bittet ein Fedora-Entwickler Sie, einen Upstream-Kernel (möglicherweise mit einem hinzugefügten Patch) zu Testzwecken zu kompilieren und zu installieren. Bei mehreren Iterationen kann dies für Sie schneller sein, als für den Entwickler, mehrere RPM-Pakete bereitzustellen.

Es gibt Bestrebungen, Vanilla-Kernel zu paketieren. Prüfen Sie zunächst, ob dies Ihren Anforderungen entspricht.

Holen der Quellen

Klonen Sie den Kernel-Baum von kernel.org. Falls Sie nicht wissen, welchen Baum Sie benötigen, sollten Sie den Baum von Linus verwenden:

git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
cd linux

Möglicherweise benötigen Sie auch den stabilen Zweig (4.y.z-Versionen), den Sie wie folgt hinzufügen können:

git remote add -f stable git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git

Patches anwenden

Patch-Dateien können Sie mit git-am anwenden:

git am -3 <Patch -Datei>

Den Kernel konfigurieren

Wenn der Entwickler Ihnen eine bestimmte Konfigurationsdatei genannt hat, speichern Sie diese im Linux-Verzeichnis unter dem Dateinamen .config

Andernfalls müssen Sie eine Konfigurationsdatei als Ausgangspunkt auswählen. Der Linux-Kernel bietet Tausende von Konfigurationsoptionen; beginnen Sie daher nicht bei Null, es sei denn, Sie wissen genau, was Sie tun.

Starten mit einer installierten Kernelkonfiguration

Wenn Sie die Konfiguration eines bereits installierten Kernels anpassen möchten, können Sie mit dessen Konfiguration beginnen, die im Verzeichnis /boot/ gespeichert ist. Um beispielsweise mit der Konfiguration des aktuell laufenden Kernels zu beginnen:

cp /boot/config-`uname -r`* .config

Starten mit dist-git

Wenn Sie die Konfiguration für einen Kernel verwenden möchten, den Sie nicht installiert haben, können Sie diese aus dem Fedora-Dist-Git-Repository beziehen. Um beispielsweise mit der neuesten Rawhide-Konfiguration zu beginnen:

cd <dist-git-Verzeichnis>
git checkout rawhide
./generate_all_configs.sh # Sicher stellen, dass die neuesten Konfigurationsdateien erzeugt werden
cp kernel-<Architektur>.config <Linux-Kernel-Verzeichnis>.config

Die Debug-Versionen der Konfigurationsdateien befinden sich in kernel-<Architektur>-debug.config, falls Sie einen Kernel mit aktivierten Debugging-Optionen erstellen möchten.

Ändern der Konfiguration

Es gibt mehrere Möglichkeiten, die Konfiguration zu ändern. Die vollständige Liste finden Sie, indem Sie make help ausführen und die Configuration targets einsehen. Ein guter Ausgangspunkt ist jedoch make menuconfig. Alternativ können Sie die Datei .config auch direkt bearbeiten.

Eine Konfigurationsoption, die Sie möglicherweise festlegen möchten, ist CONFIG_MODULE_COMPRESS. Diese komprimiert die Module (standardmäßig mit gzip) bei der Installation. Ohne diese Einstellung können die Module sehr groß werden.

Bau des Kernels

Sobald Sie den Kernel konfiguriert haben, können Sie ihn kompilieren. Vorher sollten Sie die EXTRAVERSION im Makefile in einen Wert ändern, den Sie später wiedererkennen. Wenn dort beispielsweise EXTRAVERSION = -rc5 steht, ändern Sie es in EXTRAVERSION = -rc5-dave:

$EDITOR Makefile

Jetzt können Sie den Kernel kompilieren:

make oldconfig
make bzImage
make modules

Den Kernel installieren

Die Installation des Kernels ist ganz einfach:

sudo make modules_install
sudo make install

Neuerstellung

Wenn Sie gebeten wurden, verschiedene Dinge auszuprobieren, ist die Vorgehensweise nach dem ersten Erstellen des Verzeichnisbaums größtenteils gleich. Es wird empfohlen, zwischen den Bauvorgängen make clean auszuführen. Dadurch bleibt die .config-Datei erhalten, sodass Sie den oben genannten Schritt überspringen und direkt mit dem Abschnitt make bzImage fortfahren können. Da wir im ersten Schritt ccache installiert haben, können nachfolgende Bauvorgänge deutlich schneller ablaufen, da der Compiler auf Dateien trifft, die sich seit dem letzten Build nicht geändert haben.

Aufräumen

Sobald Sie den Kernel getestet und einen Ihrer aus einem RPM installierten Kernel wieder gestartet haben, können Sie die Dateien bereinigen, die durch das obige Verfahren installiert wurden.

Achten Sie bei der Ausführung der folgenden Befehle unbedingt darauf, die richtige Kernel-Version anzugeben!

Da Sie EXTRAVERSION im Makefile geändert haben, um ein „Tag“ hinzuzufügen, enthalten alle installierten Dateien dieses „Tag“ im Dateinamen. Sie können daher Platzhalter verwenden, um diese Dateien sicher mit Befehlen ähnlich den unten stehenden zu löschen (ersetzen Sie einfach „dave“ durch das von Ihnen gewählte Tag):

rm -f /boot/config-*dave* /boot/initramfs-*dave* /boot/vmlinuz-*dave* /boot/System.map-*dave*
rm -rf /lib/modules/*dave*

Abschließend müssen Sie den Kernel als Option in Ihrem Bootloader entfernen. Vorausgesetzt, Ihr System verwendet GRUB2, kann dies durch Entfernen der Bootloader-Spezifikationseinträge und anschließende Neuerstellung der GRUB-Konfiguration erfolgen:

rm -f /boot/loader/entries/*dave*
grub2-mkconfig -o /boot/grub2/grub.cfg