Diskussion:FreeBSD/Softwarepflege
Single User Mode[Bearbeiten]
Innerhalb einer Generation[Bearbeiten]
In der Doku steht überall, dass man das Update im Single User Mode durchführen soll. Das ist aus akademischer Sicht sicherlich korrekt, in der Praxis häufig nicht anwendbar, z.B. wenn das zu pflegende System nur "durchs Schlüsselloch" (via ssh) administriert werden kann. Aus der praktischen Erfahrung heraus find Updates innerhalb eines Release-Zweiges im normalen Betrieb möglich, z.B. Update von RELENG_6_0 auf RELENG_6_2.
Update über eine Generationsgrenze hinweg (Kamikaze)[Bearbeiten]
Mit etwas Vorsicht kann man das auch über Releasegrenzen hinweg durchführen, so konnte ich schon ein RELENG_5_4 auf RELENG_6_2 updaten ohne dafür in den Single User Mode wechseln zu müssen. Hierbei war allerdings erforderlich, dass make installkernel und make installworld vor dem Reboot erfolgen. Es gibt hier auch keinen 2. Versuch, wenn der Reboot fehlschlägt. Möglicherweise kommt es beim shutdown(8) zu einer Kernel-Panic, die bei entsprechender Konfiguration jedoch zu einem automatischen Reboot anch 15sec führt. Da der erforderliche Kernel bereits installiert ist, ist das zu verschmerzen.
offline Update[Bearbeiten]
Bei der Migration eines alten RELENG_4_10 Systems von realer Hardware in ein Jail habe ich schon erfolgreich ein offline Update auf 6.2 durchgeführt. Dazu wurde per dump(8) und restore(8) das gesamte System in /data/jails/<systemname>/ übertragen und dann ausgehend vom Jailhost aus ein make installworld DESTDIR=/data/jails/<systemname>/ gefolgt von mergemaster(8) -D/data/jails/<systemname>/ das gesamte Basissystem auf RELENG_6_2 upgedatet. Das Jail startete nach ein paar Änderungen in /etc problemlos.
Analog lässt sich ein Update auch durchführen, indem man schon bei der Erstinstallation der Systems 2 Boot-Partitionen anlegt. Ausgehend vom laufenden Produktivsystem kann man offline ein Update auf die nächste Generation in der Maintenance-Partition durchführen, z.B. von RELENG_6_2 auf RELENG_7_0, und diese mit Frischen Sourcen versehen (per cvsup). Das System wird dann über den Bootmanager in die Maintenance-Partition gebootet. Dort wird das frische System zunächst nochmal getestet, ggf. nochmal frisch kompiliert und rebootet. Wenn das neue Release in der Maintenance-Partition sauber funktioniert, kann man ausgehend von /usr/src ein make installkernel KERNCONF=MEINKERNEL DESTDIR=/produktiv/ und make installworld DESTDIR=/produktiv/ ausführen, gefolgt von mergemaster(8) -D/produktiv/. Dies natürlich nur mir einem frischen und funktionierenden Backup von /produktiv/!
--rabe 22:34, 28. Jul. 2007 (CEST)
