Datenhalte

Diese Seite ist nicht editierbar. Sie können den Quelltext sehen, jedoch nicht verändern. Kontaktieren Sie den Administrator, wenn Sie glauben, dass hier ein Fehler vorliegt.
====== Kompilieren eines benutzerdefinierten Kernels ======

Es wird vorausgesetzt, dass OpenBSD mit den vollständigen Compilern (GCC, LLVM/Clang) installiert wurde. Zum Zeitpunkt der Erstellung dieses HowTo's wurde OpenBSD in der Version 7.0 für die 32-Bit Intel x86 Architektur verwendet.

===== Beziehen des Source Codes für den Kernel =====

Zuerst müssen die Kernel-Quellen bezogen werden. Dafür stehen etliche FTP- und Web-Server als Mirrors zur Verfügung. Im Beispiel habe ich mich für einen FTP-Server der Hochschule Esslingen entschieden.

<code>
$ ftp -a ftp://mirror.hs-esslingen.de/pub/OpenBSD/7.0/
Trying 129.143.116.10...
Connected to rhlx01.hs-esslingen.de.
220 beat me, break me! vsftpd, yeah baby!
331 Please specify the password.
230-
230-Rsync access available upon request.
230-
230-  All transfers are logged.
230-  If you don't like this policy, then disconnect now.
230-
230-This archive is running on a quad Opteron at 2200 Mhz each. Diskspace
230-is currently around 4 TB using ext3 as filesystem. The average through-
230-put is around 1.5 TB per day.
230-
230-This is the official anonymous FTP server of the Computing Center of the
230-University of Applied Sciences, Esslingen. http://www.hs-esslingen.de/rz/
230-
230-This is an experimental FTP server. If you have any unusual problems,
230-please report them via e-mail to adrian@hs-esslingen.de and we will
230-do our best to help you.
230-
230-	  				   	      ... powered by Linux!
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
200 Switching to Binary mode.
250 Directory successfully changed.
ftp> get sys.tar.gz
local: sys.tar.gz remote: sys.tar.gz
150 Opening BINARY mode data connection for sys.tar.gz (40120806 bytes).
100% |*****************************************************************************************************************************************************| 39180 KB    00:46
226 Transfer complete.
40120806 bytes received in 46.75 seconds (837.99 KB/s)
ftp> quit
221 Goodbye.
</code>

Wurde mit **pkg_add** das Programm **wget** installiert, so kann das komprimierte Tar-Archiv auch mit einem Befehl vom Mirror heruntergeladen werden, ohne sich mit dem FTP-Server erst verbinden zu müssen.
<code>
$ wget ftp://mirror.hs-esslingen.de/pub/OpenBSD/7.0/sys.tar.gz
</code>

Nun muss das Tar-Archiv noch entpackt werden. Dafür sind Root-Rechte nötig.
<code>
$ su
Password:
# cd /usr/src
# tar xfz home/sommteck/sys.tar.gz
</code>

===== Erstellen eines benutzerdefinierten Kernels =====

Sämtliche Kernel-Optionen werden bei OpenBSD nicht in einer Konfigurationsdatei geregelt, sondern auf zwei Dateien gesplittet. In einer der beiden Dateien wird der Hardwareteil konfiguriert – also der Architektur-spezifische Teil wie Treiber für Busse, Netzwerkkarte, Soundkarte oder ACPI-Einstellungen. In der anderen Konfigurationsdatei wird der Architektur-unabhängige Teil eingestellt, wie die unterstützten Dateisysteme, Netzwerkprotokolle und Kernel-Debugging-Utilitys wie KTrace. Theoretisch können auch alle Einstellungen in einer Datei geregelt werden, der Ordnung halber wurde der Architektur-unabhängige Teil in einem eigenen Ordnerbereich der Kernel-Sourcen ausgelagert. In der Architektur-spezifischen Konfigurationsdatei wird dann auf den unabhängigen Teil verwiesen.\\
Es ist zu empfehlen, dass bei beiden Konfigurationsdateien je eine Kopie unter einem schlagkräftigen Namen als Dateinamen erstellt wird.

<code>
# cd /usr/src/sys/conf/
# cp GENERIC CUSTOM
</code>

Mit dem Texteditor der eigenen Wahl wird dann die eigene Konfigurationsdatei bearbeitet.\\

<code>
# cd /usr/src/sys/arch/i386/conf/
# cp GENERIC CUSTOM
</code>

In der Konfigurationsdatei für den Architektur-spezifischen Einstellungen muss der Verweis auf die Datei mit den unabhängigen Einstellungen von:
<code>
…
include	"../../../conf/GENERIC"
…
</code>

zu
<code>
…
include	"../../../conf/CUSTOM"
…
</code>

abgeändert werden.

Konfigurieren des Builds mit der CONFIG-Datei:

<code>
# config CUSTOM
/usr/src/sys/arch/i386/compile/CUSTOM/obj -> /usr/obj/sys/arch/i386/compile/CUSTOM
config  -b /usr/src/sys/arch/i386/compile/CUSTOM/obj  -s /usr/src/sys /usr/src/sys/arch/i386/conf/CUSTOM
</code>

Falls unter der Kernel-Bezeichnung zumindest bereits der Kompilierungsvorgang eines Kernel mal begonnen wurde, muss der neue Build vorbereitet und alle übrig gebliebenen Objekt-Dateien entfernt werden.
<code>
# cd ../compile/CUSTOM/
# make clean
rm -f *bsd *bsd.gdb *.[dio] [a-z]*.s assym.*  gap.link gapdummy.c ld.script lorder makegap.sh param.c
</code>

Kernel kompilieren:
<code>
# make
</code>

Nachdem der neue Kernel kompiliert wurde, kann er in das Wurzelverzeichnis kopiert werden. Danach den Computer mit dem neuen Kernel neu starten.
<code>
# mv /bsd /bsd.generic
# cp /usr/obj/sys/arch/i386/compile/CUSTOM/bsd /bsd
# reboot
</code>

===== Reorder Kernel Fehler =====

Mit OpenBSD Version 6.1 wurde //**K**ernel **A**ddress **R**andomized **L**ink// als eine neue Funktion zum Schutz des Betriebssystemkerns eingeführt. //**KARL**// verbindet die Bestandteile des Kernels in zufälliger Reihenfolge. Dies passiert bei der Installation, bei jedem Upgrade und bei jedem Neustart des Systems. Das heist, dass OpenBSD bei jedem Start einen einzigartigen, neu zusammengewürfelten Kernel erhält. Das Problem am //**KARL**// ist, dass es keine benutzerdefinierte Kernel unterstützt. Deswegen wird nach dem Boot-Prozess in der Standard-Ausgabe immer folgende Fehlermeldung erscheinen.
<code>
…
reorder_kernel: failed -- see /usr/share/relink/kernel/CUSTOM/relink.log
…
</code>
In dem Logfile steht dann immer der Hinweis, dass die Prüfsumme des //**/bsd**//-Kernels nicht überprüft werden konnte und daher kein zufällig verknüpfter Kernel gebaut werden konnte. Um das Kernel Address Randomized Linking für den nächsten Systemstart wieder zu aktivieren, soll als root-Benutzer dann der Befehl '**sha256 -h /var/db/kernel.SHA256 /bsd**' eingegeben werden. Da das System aber ständig mit dem benutzerdefinierten Kernel genutzt werden soll, wird dieser Befehl nichts bewirken und immer wieder in den selben Fehler laufen. - Auch wenn die SHA256-Prüfsumme des neuen Kernels in der Datei //**/var/db/kernel.SHA256**// geschrieben wird.

===== Booten des Systems mit dem alten Kernel =====

Auch wenn Konfiguration des Kernels mit dem Befehl **config** und der Kompilierungsvorgang selber fehlerfrei durchliefen, kann es dann immer noch passieren, dass das System beim Boot-Vorgang mit dem neuen Kernel stoppt. Dann ist das System mit dem neuen Kernel erst einmal unbenutzbar. Es ist aber möglich, am Boot-Prompt den Pfad auf einem anderen - in dem Fall am besten den des generischen Standard-Kernels - zu verweisen. Der Boot-Prompt erlaubt dazu sogar den Befehl **ls**, um in im Verzeichnis zu suchen.

<code>
Using drive 0, partition 3.
Loading...
probing: pc0 apm mem[632K 3001M 780K 124K 36K a20=on]
disk: hd0+
>> OpenBSD/amd64 BOOT 3.28
boot> h
commands: # boot echo env help ls machine reboot set stty time
machine: boot comaddr diskinfo memory
boot> ls
drwxr-xr-x 0,0  512     .
drwxr-xr-x 0,0  512     ..
-rwxr----- 0,0  3899870 bsd
-rw------- 0,0  3910153 bsd.rd
drwxr-xr-x 0,0  512     usr
drwxr-xr-x 0,0  512     altroot
drwxr-xr-x 0,0  1024    bin
drwxr-xr-x 0,0  19968   dev
drwxr-xr-x 0,0  1536    etc
drwxr-xr-x 0,0  512     home
drwxr-xr-x 0,0  512     mnt
drwx------ 0,0  512     root
drwxr-xr-x 0,0  1536    sbin
drwxr-xr-x 0,0  512     tmp
drwxr-xr-x 0,0  512     var
-rw-r--r-- 0,0  578     .cshrc
-rw-r--r-- 0,0  468     .profile
drwer-xr-x 0,9  512.    sys
-rw-r--r-- 0,0  88408   boot
-rwx------ 0,0  3899870 bsd.booted
-rwx------ 0,0  14615626        bsd.generic
boot> boot /bsd.generic
</code>

===== Links =====

- https://www.openbsd.org/faq/faq5.html#Custom (OpenBSD FAQ: Custom Kernels)\\
- https://www.heise.de/ix/meldung/OpenBSD-KARL-Fuer-jeden-Start-ein-neuer-Kernel-3767821.html (Heise)