Kategorien
Allgemein

Abenteuer Update

Alle Jahre wieder, jedesmal, wenn von meiner bevorzugten Distribution eine neue Version herauskommt, juckt es mich in den Fingern, sie auf allen meinen Rechnern zu installieren. Die letzten eineinhalb Jahre blieb zumindest mein sogenannter Familienserver von diesen Anwandlungen verschont, vor dem Update des Sempron-Servers unter SUSE 9.3 mit vier Partitionen mit Crypto-Filesystem schreckte ich dann doch zurück.

Jetzt wurde es dann aber doch Zeit, wie mir mein Gefühl sagte. Und damit das Ganze nicht zu einer einfachen Spielerei wird, habe ich zu den drei schon eingebauten Festplatten gleich noch eine dazugeschraubt und eine Speichererweiterung von 512 MB auf ein GB RAM sollte es auch noch sein.

Die zusätzliche Festplatte sollte dazu dienen, die verschlüsselten Partitionen leerzuräumen, damit etwaige Probleme beim Update nicht zu Datenverlusten führen. Der Fahrplan sah also so aus:

  • neue Festplatte einbauen, mit ext3 formatieren und ins System einhängen
  • Daten von den alten verschlüsselten Partitionen auf die neue Platte kopieren
  • verschlüsselte Partitionen aushängen, neu mit ext3 formatieren und wieder ins System einhängen
  • zusätzlichen RAM einbauen
  • System auf openSUSE 10.2 updaten

Liest sich einfach, klingt ausreichend vorsichtig, sollte ohne Probleme und ohne Datenverluste funktionieren.

Das erste Problem entstand schon beim Einbau der neuen Festplatte. Bei dem Server handelt es sich um den c’t-Servervorschlag von Anfang 2005, Platz ist im Gehäuse zu Genüge vorhanden und das Gehäuse ist auch wartungsfreundlich genug, um an alles gut heranzukommen. Allerdings liegen zwei der vier SATA-Buchsen auf dem Mainboard so nah am Prozessor, dass sie vom überbreiten CPU-Kühler teilweise überragt werden. Nach ein bisschen Fummelei wird das alte System hochgefahren, aber eine der alten Festplatten mit Crypto-Partition wird nicht mehr erkannt.

Also das Gehäuse wieder geöffnet, SATA-Kabel drei und vier vertauscht, schon klappt’s auch mit den vier Festplatten. Scheinbar mögen verschlüsselte Festplatten es überhaupt nicht, wenn sich ihr Platz im System ändert, z.B. von sdc auf sdd, was in meinem System durch hinzufügen der vierten Platte urplötzlich der Fall war. Durch’s umstecken landete die Platte wieder auf sdc, alles paletti.

Der nächste Teil war einfacher, die neue Platte hatte genug Platz, um die Daten von zwei der vier verschlüsselten Partitionen dort unterzubringen. Spannend wurde es dann wieder beim Entfernen der Cryptopartitionen mittels YaST. Man könnte meinen, wenn man einfach den Haken für „verschlüsselt“ entfernt, hätte das schon einen positiven Effekt. Ganz so einfach war’s dann aber doch nicht. Mehrere Trial-and-Error Phasen brachten folgende Herangehensweise als erfolgversprechend zutage:

verschlüsselte Partition leeren in YaST:

  • die verschlüsselte Partition aushängen (klappt nur, wenn man das Passwort eingibt)
  • die verschlüsselte Partition entfernen (klappt nur, wenn’s die letzte auf der Festplatte ist)
  • freien Platz neu partitionieren und wieder einhängen

Was mir dann das Genick gebrochen hat war, dass ich versucht habe, auf diese Art auch zwei verschlüsselte Systempartitionen (/home und /srv) zu verlagern. Mit /srv klappte das noch, aber die Verlagerung von /home nahm das System sehr übel. Ausserdem meckerte YaST die ganze Zeit, eine der Festplatten (sdc) habe eine RAID-Konfiguration (keine Ahnung, wie die dahin gekommen sein soll). Mittlerweile vermeldete parted auch nur noch Unsinn, die Extended Partition sda2 wurde nur noch mit einer unbekannten Größe angegeben und sda war generell gegen die Bearbeitung mit parted gesperrt. Tja, also versuchen wir doch jetzt mal das Update, schlimmer geht’s ja nimmer…

…oder doch! Die Box-Version SUSE 10.2 lief bis zum Erkennen der Partitionierung, dann brach das Update ab. Auch das Partitionierungstool der 10.2 versagte den Dienst. Guter Rat war teuer aber dank meines Rechnerzoos nicht weit. GPartEd herunterladen und Brennen dauerte nur fünf Minuten. GPartEd zeigte nun überhaupt keine Partitionen auf sda an, obwohl sich dort eine alte primäre Root-Partition, eine /home und eine /var tummeln sollten. OK, es ist ein Server, die /home-Dateien sind auf zwei anderen Festplatten gespiegelt. Update macht sowieso keinen Spass, also einfach die ganze Platte neu formatieren und hinterher ein jungfräuliches System aufspielen. Dass ich dabei meine ausgefeilte smb.conf verlor, merkte ich natürlich erst später.

Nach dem Intermezzo mit GPartEd lief die Installation mit SUSE 10.2 scheinbar problemlos, die zusätzlichen Festplatten liess ich erstmal ungemounted, den Samba-Share wollte ich sowieso erst später zusammenstellen. Oha, da kam die Erinnerung an meine optimierte smb.conf R.I.P.

Weit kam ich mit der Installation aber sowieso nicht, beim Schreiben der grub-Konfiguration brach die Installation mit der Meldung ab, es könnte die Platte, auf die geschrieben werden soll, nicht finden. Tja, zehn Jahre Linux-Installationen und trotzdem gelingt es SUSE, mich mal mit einer neuen Fehlermeldung zu überraschen.

Auch eine Analyse mit dem Rettungssystem und ein zweiter Installationsversuch brachte keinen Erfolg. In früheren Zeiten hätte man einfach lilo auf eine Diskette installiert und von da gebootet. Ein Diskettenlaufwerk hat der Server allerdings nicht. Nun war aber auch erstmal Schluß, derartige Probleme klärt man nicht mehr am späten Abend. Während ich mir morgens ein aktuelles Knoppix aus dem Internet lud, probierte ich statt der DVD aus der SUSE-Box meine selbstgebrannte DVD mit openSUSE 10.2 aus lauter Langeweile auch noch aus. Die Installation lief problemlos durch, grub wurde einwandfrei installiert, das System lief und läuft seitdem immer noch.

Ich hoffe bloß, mich fragt niemand, warum ich mir die eine oder andere freie Minute über Weihnachten um die Ohren gehauen habe. Das Einzige, was jetzt besser funktioniert als früher ist, dass die onboard-Netzwerkarte jetzt geht und ich auf die RealTek-PCI-Karte verzichten kann. Ob das den mehrstündigen Zeitaufwand rechtfertigt, würde ich sogar vor mir selbst bezweifeln 🙂 Zumal sich damit die IP-Adresse, die sich der Server per dhcp holt, geändert hat, was ich SWMBO zusätzlich zur investierten Zeit auch noch erklären musste. Aber es geht eben nichts über aktuelle Betriebssysteme…

Schreibe einen Kommentar