 "Aufmacher Artikel")
The Answer Girl
Dass der Computeralltag auch unter Linux des Öfteren für Überraschungen gut ist, ist eher eine Binsenweisheit: Immer wieder funktionieren Dinge nicht oder nicht so, wie eigentlich angenommen. Das Answer-Girl im LinuxUser zeigt, wie man mit solchen Problemchen elegant fertig wird.
Über den Tellerrand zu schauen – dieses Motto des letzten "Answer Girls" [1] stieß den Leser-Zuschriften zufolge auf ein ausgesprochen positives Echo. So raffen wir uns in dieser Ausgabe dazu auf, das installierte FreeBSD-System ein wenig näher zu inspizieren. Mittlerweile halten die diversen Mirror bereits Version 4.7 bereit, so dass die denn auch die Grundlage dieses Artikels bildet. Doch zu diesem Zweck müssen wir erst einmal updaten.
Erstmal ein Upgrade
Ein Binär-Upgrade von der Vorgängerversion 4.6 ist recht leicht über das schon von der Installation her bekannte Tool /stand/sysinstall möglich (Abbildung 1). Als root von der Kommandozeile aufgerufen, wählen wir darin den Punkt Upgrade aus und bestätigen, dass wir uns über Risiken und Nebenwirkungen im Klaren ist. Wen jetzt doch noch die Panik überfällt, bricht das sysinstall-Programm mit [Strg-C] und anschließender Auswahl des Menüpunktes Abort ab.
Das tun wir an dieser Stelle tatsächlich, um uns die leidvolle Erfahrung zu ersparen, dass zwar massenweise Daten auf die Festplatte geschaufelt werden, am Ende aber doch keine Version 4.7 zur Verfügung steht. Der gar nicht so leicht zu findende Grund: sysinstall "weiß" ohne aktiven Eingriff der Installateurin weder, dass es eine neue Version gibt, noch dass sich das Upgrade-Begehren darauf bezieht. Stattdessen aktualisiert die Auswahl des Punktes Upgrade immer die derzeit eingestellte Version; bei einer FreeBSD-4.6-Installation also diese "mit sich selbst". Das ist auch sinnvoll, denn schließlich fallen immer wieder mal Security-Updates an, ohne dass an der FreeBSD-Versionsnummer gedreht wird.
Doch wie erfährt sysinstall, dass nicht das Update der aktuell installierten Version, sondern ein Upgrade auf die neue 4.7 auf dem Plan steht? Gut versteckt, nämlich im Menü Configure gibt es einen Punkt
Options View/Set various installation options
Wählen wir diesen aus, so erscheint der Options Editor (Abbildung 2), in dem der Wert des Parameters Release Name zur Debatte steht: Für ein Upgrade von 4.6 auf 4.7 muss der String 4.6-RELEASE in 4.7-RELEASE geändert werden. Zu diesem Zweck geht root mit der Pfeiltaste nach unten auf die entsprechende Zeile und drückt die [Leer]-Taste. Dies bringt ein Zeileneditor-Fensterchen namens Value Required (Abbildung 2) auf den Plan, in dem wir den Wert korrigieren und anschließend mit [Enter] bestätigen. Ein [q] und die Wahl des Punktes
X Exit Exit this menu (returning to previous)
bringt die Installateurin zurück zum Hauptmenü, von wo aus sie einen erneuten Upgrade-Versuch startet.
Neuer Anlauf
Die erste echte Entscheidung gilt es nun zu treffen, wenn die Frage nach der upzudatenden Distribution aufkommt: Wer sich bei der Installation für das umfassende X-Kern-Developer-Set entschieden hat, sollte das an dieser Stelle wieder tun. Auch die Frage, ob die Ports-Kollektion installiert werden soll, bestätigen wir und wählen anschließend den Menüpunkt Exit.
sysinstall informiert nun darüber, dass in /usr/src installierte Quellcode-Pakete beim beabsichtigten Binär-Update nicht auf den neuesten Stand gebracht werden, und erfragt, wohin es ein Backup des Konfigurationsverzeichnisses /etc ablegen soll (Abbildung 3). Nach dem Upgrade spielt sysinstall die dortigen Daten wieder an ihren alten Platz zurück, so dass sich das System anschließend wieder individuell konfiguriert präsentiert. Die neuinstallierten Konfigfiles liegen zum Vergleichen (etwa mit dem sehr nützlichen Kommandozeilentool sdiff) in /etc/upgrade vor. Auch der alte Kernel wird für den Fall, dass das Upgrade schief geht, unter /kernel.prev gesichert.
Abbildung 1: Bevor man "Upgrade" wählt, sollte man zwingend dem Punkt "Configure" einen Besuch abstatten
Abbildung 2: Nur wer den Versionsnamen anpasst, kann auf eine neue Version upgraden
Abbildung 3: Solange der Platz in /var/tmp reicht, ist dies ein guter Ort für ein Backup der Systemkonfigurationsdateien
Soll das Update von einem Datenträger-Set oder vom Netz installiert werden? Wenn letzteres der Fall ist, gilt es, einen passenden Server möglichst in der Nähe auszuwählen. Zu Redaktionsschluss hatte von den deutschen Servern nur ftp://ftp7.de.FreeBSD.org die neue Version 4.7 auf Lager, inzwischen dürften auch die anderen Mirrors nachgezogen haben. Eine kurze Abfrage, ob das Netzwerk konfiguriert ist, und schon geht's los …
Nach dem eher unspektakulären Ende der Installation beenden wir sysinstall über die Schaltfläche [X Exit Install] (Abbildung 1) und landen kommentarlos wieder in der root-Shell. Zum Starten des neuen Kernels muss jetzt nur noch ein Reboot her (auch hier funktioniert der von Linux bekannte "Affengriff" [Strg-Alt-Entf]), und der kann sich als tückisch erweisen, wie Kasten 1 zeigt.
Kasten 1: Allein mit dem Bootmanager
Da rebootet man das neue System erwartungsfroh, und dann – oh Schreck! – meldet der Bootloader BootEasy
Unable to load kernel: Aborted!
Jetzt ist Ruhe bewahren angesagt: Während der Schrecksekunde versucht es der Bootloader zwar noch ein zweites Mal, doch da auch dies misslingt, bricht er ab und lässt die Benutzerin mit einem ok-Prompt allein:
Type '?' for a list of commands, 'help' for more detailed help. ok
Drückt sie nunmehr [Shift]-[-], so ergibt das bei der derzeitig aktuellen amerikanischen Tastenbelegung auf deutschen Keyboards das gewünschte Fragezeichen. Ein [Enter] dahinter, und schon listet der Bootloader alle möglichen Kommandos auf, darunter auch
boot boot a file or loaded kernel load load a kernel or module
boot und [Enter] am ok-Prompt eintippen schadet nichts – wenn BootEasy lapidar
can't load 'kernel' can't load 'kernel.old' no bootable kernel
meldet, ist klar: Er hat einfach keinen passenden Kernel gefunden. Doch sagte die Update-Routine nicht, dass sie den alten Kernel unter /kernel.prev abgespeichert hat? Dann laden wir doch diesen versuchshalber:
ok load kernel.prev /kernel.prev text=0x2c6f35 data=0x46db4+0x3dea0 syms=[0x4+0x3d820+0x4+0x43e32] ok
Scheint geklappt zu haben – der alte Kernel wurde geladen. Nun muss er nur noch booten, und das geht tatsächlich mit einem einfachen boot [Enter]. Einmal hochgefahren, könnte root den alten Kernel mit mv /kernel.prev /kernel unter dem Namen kernel ablegen, nach dem BootEasy sucht – und schon bootete das System wieder ohne manuellen Eingriff.
Doch wozu soll das ganze Upgrade gut sein, wenn wir uns am Ende doch mit dem alten Kernel bescheiden? Etwas Detektivarbeit ist angesagt: Zunächst einmal wissen wir aus der obigen Meldung, dass BootEasy von sich aus versucht, einen Kernel aus der Datei kernel zu laden, und wenn das nicht funktioniert, nach kernel.old schaut. Da wir den unter /kernel.prev liegenden Kernel mit load kernel.prev ohne Pfadangabe laden konnten, bedeutet das nichts anderes, als dass sich auch andere, unterhalb von / abgelegte Kernel-Dateien einfach unter ihrem Namen ansprechen lassen.
Da es nicht sehr wahrscheinlich ist, dass die FreeBSD-Entwickler den neuen 4.7er Kernel in einer gänzlich anders getauften Datei ablegen, schauen wir doch einfach einmal, welche kernel-Dateien das Root-Verzeichnis zu bieten hat:
# ls -l /kernel* -r-xr-xr-x 1 root wheel 4028952 Oct 9 17:08 /kernel.GENERIC -r-xr-xr-x 1 root wheel 3773566 Oct 11 16:49 /kernel.prev
Vom Zeitstempel her muss kernel.GENERIC der neue Kernel sein (FreeBSD 4.7 erschien am 10. Oktober; beim Update am 11. Oktober legte sysinstall das Backup des alten 4.6er Kernels in kernel.prev ab). Wir könnten also direkt am BootEasy-Prompt load kernel.GENERIC eingeben, aber wozu die Umstände? Aus der Bootloader-Meldung war schließlich zu erkennen, dass BootEasy mit kernel und kernel.old Dateien für den alten und den neuen Kernel vorsieht, die automatisch geladen werden. Das Anlegen symbolischer Links sollte demnach reichen:
cd / ln -s kernel.GENERIC kernel ln -s kernel.prev kernel.old
Mit sync; reboot heruntergefahren und neu gestartet, darf der Rechner dann tatsächlich automatisch FreeBSD 4.7 hochfahren. Zeigen lässt sich dies spätestens nach dem Einloggen:
$ uname -a FreeBSD testmaskin.linuxnewmedia.de 4.7-RELEASE FreeBSD 4.7-RELEASE #0: Wed Oct 9 15:08:34 GMT 2002 root@builder.freebsdmall.com:/usr/obj/usr/src/sys/GENERIC i386
BootEasy lässt sich, während es einen Kernel lädt, übrigens immer durch Druck einer beliebigen Taste ([Esc] oder [Tab] bieten sich an) dazu überreden, in den interaktiven Modus zu gehen. Will man nun jedoch einen anderen Betriebssystemkern laden (und anschließend booten), muss der alte zunächst mit unload entladen werden.
Einem Freund empfehlen
