FreeBSD 8.0 mit IPsec auf sparc64 => Kernel Bug

Warum sollte man einen eigenen Kernel unter FreeBSD bauen wollen?
Grundsätzlich braucht man das wohl eher nicht. Der Vanilla-Kernel (Standard-Kernel) ist gut genug. Es sei denn, man möchte noch mehr haben/ machen oder seinen Kernel schlanker machen.
Was soll der Kernel WLAN unterstützen, wenn man definitiv nie mit WLAN an seinem Server zu tun haben wird? Warum sollte der Treiberunterstützung für Soundkarten mitbringen, die in einem Server wohl auch nie eingebaut werden sollte? Oder Treiber für Netzwerkkarten mit GBit und 10-GBit Anschluss?

Mein Server braucht ein paar Dinge (WLAN, Sound, GBit, Firewire usw.) im Kernel derzeit nicht. Dafür hatte ich allerdings eine Sache gefunden, die im Standardkernel nicht mit drin ist: IPsec. Warum das nicht gleich mit ausgeliefert wird, ich weiß es nicht. Dieses in dne Kernle einbauen ist aber auch nicht sonderlich kompliziert. Soweit zumindest die Theorie…

Eine gute Anleitung zum Bau eines eigenen Kernels findet sich auf den Handbook Seiten von FreeBSD. Darin ist auch beschrieben, was für IPsec Optionen in der Kernelkonfigurationsdatei zusätzlich hinzukommen müssen. Eigentlich sind das nur zwei Zeilen, die man zu den schon bestehenden einfügen muss.

options IPSEC #IPsec Eintrag im Bereich option
device crypto # Device Eintrag

Grundsätzlich gilt: Konfiguration anpassen, danach einmal das „normale“ Kernelbauprozedere durchlaufen lassen, Kernel installieren, rebooten (und beten…). Kernelsourcen sind u.U. über sysinstall nachzuinstallieren.

Sieht also ungefähr so aus:
– Wir haben unter /usr/src/sys/$ARCH/conf/ ($ARCH ist durch die passende CPU Architektur zu ersetzen; für Sparc4U CPUs wäre es sparc64) eine Datei GENERIC liegen. Die kopieren wir nach /root/kernels/ und benennen sie gleichzeitig in IPSECKERNEL um:
cp GENERIC /root/kernels/IPSECKERNEL
– Wir setzen einen symbolischen Link
ln -s /root/kernels/IPSECKERNEL /usr/src/sys/sparc64/conf/IPSECKERNEL
– Wir bearbeiten diese und fügen die obigen Zeilen ein und entfernen vll. die ein oder andere aus dem Kernel.
– Wir wechseln mit cd /usr/scr/ in das Sourceverzeichnis
– Dort starten wir den Bau des Kernels mit
make buildkernel KERNCONF=IPSECKERNEL
– Nun haben wir Geduld. Vieeel Geduld. (Braucht bei betagter Hardware schon ein paar Stündchen…)
– Sollten Fehlermeldungen auflaufen, bricht der Bau ab. Aus den Meldungen sollte man schon ersehen können, was falsch gelaufen ist. Abhängigkeiten sind bei einigen Dingen untereinander nötig und müssen erfüllt sein. Man kann also nicht device wlan rauswerfen und WLAN Hardware in den Kernel bauen wollen…
– Wenn der Bau erfolgreich war, gibt’s eine Fertigmeldung.
– Danach kann der Kernel installiert werden
make installkernel KERNCONF=IPSECKERNEL
Der bisherige Kernel wird dabei nach /boot/kernel.old geschoben. Man sollte sichergehen, dass mindestens dieser (vll. noch ein Originalkernel) unter /boot/ liegen und namentlich bekannt sind.
Nach der Installation: Reboot. Warten und das System sollte bald wieder erreichbar.

Soweit grundsätzlich zur Kernelbaugeschichte.

Nun wieder zurück zur Problematik mit meinem System:
Die zwei Zeilen sind für IPsec und dem dazugehörenden Device zuständig und wurden an passender Stelle eingefügt. Den Kernel habe ich nach Vorgabe gebaut, installiert und einen „Notfallkernel“ für den Fall der Fälle. Alles sah soweit gut aus.
Danach kann man, sofern man seiner eigenen Arbeit vertraut, rebooten. Also den Server rebootet.
Und was passierte? War (nach Murphy) eigentlich ja auch zu erwarten: Der Server wollte nicht wieder booten. Der danach nötige Zugriff, um dem System wieder Leben einzuhauchen, zeigte ein Problem. Mein Kernel meinte, dass es kein root Filesystem mehr mounten wollte/ konnte/ was auch immer.
Kernel Fehler und System will nicht booten??? Wieso jetzt das? Sofern ich das richtig in Erinnerung hatte, flog nichts aus der Konfig raus, was irgendwas mit wichtigen Komponenten zu tun hatte. Es sind nur die zwei obigen Zeilen hinzugekommen und ein paar Dinge rausgewandert. Nichts, was irgendwie mit Zugriff auf Festplatten, PCI und so weiter zu tun hatte.
Also erstmal wieder den vorherigen Kernel gebootet. Kurze Beschreibung, wie man den defekten Kernel entlädt und den alten (sofern der denn noch funktionierte und man diesen nutzen kann) wieder startet findet man auf den FreeBSD Handbook Seiten.
Beim Bootvorgang (Loader lädt) ESC Taste drücken, man landet auf dem OK Prompt.

OK> unload kernel
OK> boot /boot/kernel.old

Dann die Konfiguration angesehen. Alles drin, was reingehört. Nächster Versuch, die letzten Meldungen des fehlerhaften Bootvorgangs angesehen:

ispfw: registered firmware
ispfw: registered firmware
ispfw: registered firmware
ispfw: registered firmware
kbd0 at kbdmux0
nexus0:
cryptosoft1: mem 0x1fe00000000-0x1fe0000ffff, 0x1fe01000000-0x1fe010000ff
irq 2032,2030,2031,2021 on nexus0
cryptosoft0: on nexus0
nexus0: type unknown (no driver attached)
Timecounter "tick" frequency 500000000 Hz quality 1000
Timecounters tick every 1.000 msec
IPsec: Initialized Security Association Processing.
Trying to mount root from ufs:/dev/ad0a
ROOT MOUNT ERROR:
If you have invalid mount options, reboot, and first try the following from the loader prompt:

set vfs.root.mountfrom.options=rw


and then remove invalid mount options from /etc/fstab.


Loader variables:
vfs.root.mountfrom=ufs:/dev/ad0a
vfs.root.mountfrom.options=rw


Manual root filesystem specification:
: Mount using filesystem
eg. ufs:/dev/da0s1a
eg. cd9660:/dev/acd0
This is equivalent to: mount -t cd9660 /dev/acd0 /


List valid disk boot devices
Abort manual input

mountroot>

Da ich weder den Eintrag für IDE noch Änderungen an der fstab vorgenommen habe, macht mich das schon etwas stutzig. Eine Kontrolle der Bootmeldungen beim "richtigen" Kernel bringt einen Unterschied zu Tage:

ispfw: registered firmware
ispfw: registered firmware
ispfw: registered firmware
kbd0 at kbdmux0
nexus0:
pcib0: mem 0x1fe00000000-0x1fe0000ffff,0x1fe01000000-0x1fe010000ff irq 2032,2030,2031,2021 on nexus0
pcib0: Sabre, impl 0, version 0, IGN 0x1f, bus A, 66MHz
pcib0: DVMA map: 0x60000000 to 0x63ffffff
pcib0: [FILTER]

Im Vergleich kommen zwei unterschiedliche Meldungen für nexus0:

nexus0: type unknown (no driver attached) (kaputter Kernel)
nexus0: (funktionsfähiger Kernel)

Also geht da irgendwas schief, was einen erfolgreichen Bootvorgang verhindert. Was, ist mir nicht ersichtlich. Einzige Änderung (mittlerweile durch ein paar weitere Kernelbauorgien nachgestell) ist der Eintrag device crypto. Was hat crypto mit syscons zu tun???

Google bringt ähnliche Probleme zum Vorschein:
http://www.jp.freebsd.org/cgi/query-pr.cgi?pr=kern/136123
http://lists.freebsd.org/pipermail/freebsd-bugs/2009-June/035852.html
http://www.jp.freebsd.org/cgi/query-pr.cgi?pr=kern/132129
Und in einer Bugzusammenfassung:
http://www.jp.freebsd.org/cgi/query-pr-summary.cgi

Allerdings schon seit dem Kernel in 7.1 Pre3 (und natürlich 7.2 Stable). Kann es sein, dass es noch immer kaputt ist und IPsec auf Sparc64 einen kaputten Kernel baut?
Der Bug auf Sparc Systemen ist noch offen. Seit nunmehr einem Jahr!
Bisher war ich großer Fan von FreeBSD und würde es ungerne von meinem Server verbannen und durch Linux oder Solaris ersetzen. Aber wenn IPsec nicht geht und ich jetzt doch IPsec "dringend" einsetzen will?


Ich bin etwas enttäuscht.

Dieser Beitrag wurde unter Dokus und Tipps, Linux/ UNIX abgelegt und mit , , , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert