Re: Update 4.x-> 6-stable (?)

From: Oliver Fromme <olli(at)lurza.secnetix.de>
Date: Tue, 24 Jan 2006 14:53:02 +0100 (CET)

Peter Ross wrote:
> Oliver Fromme wrote:
> > PS: Nur so am Rande: Ich habe am Wochenden einen Rechner
> > mit 4.0-current vom September 1999 auf den aktuellen Stand
> > gebracht, und zwar per Binary-Upgrade, da es per Source nicht
> > machbar war (486-DX2-66, 32 Mbyte RAM, 1.5GB Platte).
> > Und das Ganze remote ohne Consolenzugang. Ziemlich span-
> > nende Sache, kann ich sagen. :-)
>
> [...] schreibe doch mal, was es dabei zu beachten gibt. Es interessiert
> einen Aussie hier (mich vielleicht auch) und ich leite das gerne weiter.
>
> Der erste Stolperstein, der mir einfaellt, ist der Kernel in /boot.

Nein, der ist (noch) in /, da ich erstmal nur auf ein
aktuelles 4-stable (nach 4.11) gegangen bin. Der Schritt
auf 6.x ist evtl. für später geplant, sollte aber auf
ähnliche Weise machbar sein. Wo der Kernel per Default
gesucht wird, läßt sich per loader.conf einstellen; das
ist also kein Problem. Und der (boot-)loader von 6.x
kann auch problemlos noch alte 4er-Kernel laden -- auch
dies ist also kein Problem. (Tatsächlich habe ich auf
dem Rechner bereits Bootstrap und loader(8) von 6.x in-
stalliert, obgleich das System noch 4-stable ist.)

Aber der Reihe nach.

Der erste und wichtigste Schritt war, /usr/src/UPDATING
zu lesen (von einem aktuellen 4-stable). Das ging in der
Tat bis zum kritischen Datum (September 1999) zurück, und
noch weiter. Das ist erstmal sehr viel, aber man gewinnt
einen groben Überblick über die kritischen Änderungen,
über die man stolpern könnte. Darunter waren z.B. auch
die Änderungen der Device-Namen von "sd" nach "da" (SCSI-
Platten) und von "wd" nach "ad" (IDE-Platten), und andere
»nette« Dinge.

Der zweite und ebenso wichtige Schritt war, bei mir unterm
Schreibtisch ein identisches System nachzubilden. Natür-
lich hatte ich nicht dieselbe Hardware, aber das war nicht
so entscheidend. Jedenfalls habe ich mit dd(1) ein Abbild
der Original-Festplatte genommen und auf eine (größere)
Festplatte in meinem Clone-Rechner aufgespielt. dd(1) des-
halb, damit auch MBR, Bootblöcke und das Layout der Datei-
systeme exakt identisch sind.

Dann habe ich das Update an dieser Kopie ausprobiert und
mir jeden einzelnen Schritt und jedes einzelne auftretende
Problem (und da gab es durchaus ein paar) notiert. Erst
nachdem ich mit dem Clone-Rechner das gesamte Update ohne
Fehler durchführen konnte, habe ich das dann auf dem Ziel-
Rechner nachvollgezogen.

Im wesentlichen waren es diese Schritte (ausm Kopf, ohne
Anspruch auf Vollständigkeit und Korrektheit):

 - /boot aktualisieren. Dies ist voll abwärtskompatibel
   (s.o.), daher völlig problemlos.

 - Neuen 4-stable-Kernel installieren. Der größte Teil des
   alten Userlands lief problemlos unter dem neuen Kernel,
   insbesondere alles, was für den Bootstrap erforderlich
   ist. /modules nicht vergessen.

 - ps, top und alles, was von der libkvm abhängt, ging
   nicht. Daher habe ich aktuelle Versionen dieser Bina-
   ries in ein separates Verzeichnis hochgeladen, damii
   ich sie nötigenfalls Zur Verfügung habe (Libraries
   nicht vergessen).

 - Neues /dev/MAKEDEV hochladen. Diese braucht auch ein
   neues /sbin/mknod (darauf wäre ich ohne den Test-Rechner
   nie gekommen), das ich also ebenfalls hochladen mußte.

 - Neue Devices anlegen (in erster Linie ad* und da*).

 - Devicename ind /dev/fstab und /etc/rc.conf anpassen.

 - Rebooten (und ggf. beten).

 - Nach dem Reboot geht's daran, das Userland zu aktuali-
   sieren. Zunächst die statischen Sachen in /bin und
   /sbin, da diese ziemlich unproblematisch sind. Dann
   die neuen Libs installieren, libdata und libexec,
   dynamische Binaries und /usr/share, dann den ganzen
   Rest.

 - Kleiner Haken: Alte Binaries funktionieren mit den
   neuen compat-Libraries nicht mehr (aufgrund geänderter
   stdin/out/err-Symbole; auch dies stand in UPDATING,
   trotzdem hat es mich auf meiner Test-Maschine gebissen).
   Daher muß man hier unbedingt auf die Reihenfolge der
   Installation achten.

 - Nicht vergessen: /etc abgleichen, insbesondere auch
   die Bootskripte (/etc/rc*) und Periodic-Skripte
   (/etc/periodic/*/*).

 - /usr/compat habe ich entsorgt, weil es nicht gebraucht
   wurde. Wenn man die Linux-Emu braucht, muß man das
   natürlich auch aktualisieren.

 - Schließlich sollten (bzw. müssen) auch alle Packages
   aktualisiert werden. Das habe ich mit brutaler Gewalt
   gemacht: rm -rf /usr/local /usr/X11R6 /var/db/pkg.
   Dann alle Pakete neu installiert, die gebraucht werden.
   Das hatte den angenehmen Nebeneffekt, daß eine Menge
   überflüssiger alter Schrott entsorgt wurde.

Gruß
   Olli

-- 
Oliver Fromme,  secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
"Clear perl code is better than unclear awk code; but NOTHING
comes close to unclear perl code"  (taken from comp.lang.awk FAQ)
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Tue 24 Jan 2006 - 14:55:04 CET

search this site