Skip to content

Mietserver-Recovery mit veraltetem Rescuesystem

Den First Dedicated Power Server S Limited Edition benutze ich seit ziemlich genau einem Jahr als Entwicklungssystem. Da die Kiste ausschließlich verschlüsselt mit der Außenwelt spricht, sind die Schwächen im Netzwerksetup des Hosters für meine Anwendung irrelevant. Als nicht irrelevant zeigten sich vor einigen Wochen die Macken im Rescuesystem, als ein Umstieg auf neue Hardware anstand.

Mein Server hat im Herbst letzten Jahres angefangen, SMART-Fehlermeldungen zu werfen, und Anfang Februar wurde es mir dann zu bunt, so dass ich ein Ticket beim Hoster aufgemacht habe. Der Hoster findet bei einer oberflächlichen Prüfung des Systems, die mit einem knappen halben Tag Downtime verbunden war, keine Fehler und tauscht mir kulanterweise das PATA-Kabel. Leider hilft das nicht, die SMART- und CRC-Fehler im Syslog tauchen schnell wieder auf.

Als nächstes versucht der Hoster, die Schuld auf mein System zu schieben ("Fehlerhaftes Dateisystem oder Bugs im verwendeten Kernel") und möchte, dass ich den Server neu aufsetze. Ich versuche das erstmal zu vermeiden und versuche das Problem mit dem Rescue-System zu reproduzieren. Das erweist sich aber als leichter gesagt als getan, denn das Rescuesystem ist - ich berichtete - so alt, dass ich damit meine Filesysteme nicht eingehängt bekomme. Und durch irgendwelche dd-Übungen ist das System nicht zum Werfen von CRC-Fehlern zu bringen.

Also rsynce ich die Daten zähneknirschend auf einen anderen Server (um mir das Restore vom Wohnungs-Backup über mein dünnes ADSL zu ersparen), mache eine Neuinstallation auf das Uralt-Standardimage des Anbieters, update auf aktuelles Debian etch mit security-Updates und beginne meine Daten draufzukopieren. Keine fünf Minuten später beginnen wieder die CRC-Fehler.

Nun ist der Hoster auch überzeugt und bietet mir den Tausch gegen eine komplett neue Maschine an, die dann auch eine neue IP bekommt. Das stört mich nicht, da ich das System ja nur inten verwende, also stimme ich zu. Leider ist es nicht möglich, Zugang auf beide Maschinen gleichzeitig zu bekommen; zuerst wird die alte abgeschaltet und dann für die neue Zugangsdaten generiert. Am Abend desselben Tages kommen die Zugangsdaten für die neue Kiste; ab dem ersten Kontakt bis hier sind sechs Tage vergangen.

Die Zugangsdaten für den neuen Server teilen mir mit, dass ich mich in das Rescuessystem mit grml@ip-adresse einloggen soll. Das funktioniert allerdings nicht, und das auf Port 22 sichtbare Banner mit dem String "Debian woody" lässt vermuten, dass ich es hier auch nicht mit einem grml zu tun habe, sondern mit dem "alten" Rescuesystem. Nach einer Stunde sind dann auch die Zugangsdaten in das System konfiguriert und ich kann mich endlich - als root - anmelden.

Wie schon im Servertest erwähnt, ist das Rescesystem von First Dedicated uralt. Es basiert irgendwo auf Debian woody, hat weder LVM-Support im Kernel noch die Userspace-Tools installiert und läuft noch mit Linux 2.4. Damit direkt mein LVM- und Linux-2.6-basierendes System wieder draufzuklatschen ist illusorisch. Also anders.

Ich entschliesse mich, wie schon bei einem anderen Hoster neulich durchgespielt, ein grml-small in die swap-Partition zu installieren. Aber dann kommt mir die Idee, dass das gar nicht not tut: Ich habe doch ein nicht im LVM liegendes ext2-Filesystem, nämlich das System, das im Produktivbetrieb als root eingehängt ist. Spricht eigentlich nichts dagegen, das grml dort abzulegen - dann steht es schneller zur Verfügung, wenn im Notfall das Root-Filesystem noch da ist. Wenn es nicht mehr da ist, kann man dann immer noch den Stunt mit dem swap-Filesystem machen.

Also wird schwupps die Platte partitioniert, das root-Filesystem auf hda1 angelegt und dessen Inhalt aus dem Backup zurückgeschoben. Nach /boot/grml kommt der Inhalt einer grml-small-CD. grml-medium hatte ich zu dem Zeitpunkt noch nicht ausprobiert; der Trick hätte aber nach den einschlägigen Erfahrungen aus der Erstellung meines Universal-Boot-Sticks auch mit grml-medium funktioniert.

Die für grml-small gültige Boot-Eintragung lautet:

title           grml
root            (hd0,0)
kernel          /boot/grml/linux26 toram grml_dir=/boot/grml/GRML/ grml_name=GRML toram ramdisk_size=100000 init=/etc/init lang=us BOOT_IMAGE=grml ssh=M9flN0A1
initrd          /boot/grml/minirt26.gz
und ich schätze, dass die für grml-medium irgendetwas rund um
title           grml-medium
root            (hd0,0)
kernel          /boot/grml/boot/grmlmedium/linux26 live-media-path=/grml-medium/live/ toram=grml-medium.squashfs lang=us boot=live noeject noprompt keyboard=de
initrd          /boot/grml/boot/grmlmedium/initrd.gz
heißen müsste. Das hab nich aber nicht ausprobiert.

Nun nur noch grub auf der Platte installieren. Unter Debian liegt das grub-Binary in /usr und steht somit im vorliegenden Zustand des Systems nicht zur Verfügung; das Rescuesystem hat kein grub. Also schwupps die binäre grub-Package aus Debian stable gezogen, mit dpkg-deb ausgepackt und... festgestellt, dass die Libraries des Rescuesystems zu alt sind um das dynamisch gelinkte grub-Binary auszuführen. Ich spare mir den Bugreport "please build a new package with statically linked grub", weil grub in Debian nicht mehr wirklich gepflegt wird - die Maintainer sind der Meinung, dass man die Arbeit besser in grub 2 stecken sollte, und ich bin der Meinung, dass bis zur rudimentären Benutzbarkeit von grub 2 noch ein wenig Wasser den Neckar wird herunter fliessen müssen.

Statt dessen wird /boot/grub in /boot/grub-backup umbenannt, ein historisches grub aus woody ausgepackt, die stages nach /boot/grub geschoben, menu.lst kopiert und auf der grub-shell installiert. Da der Server keine serielle Konsole hat, muss mit dem default-Keyword gearbeitet werden (die Einträge zählen ab Null, #451709), und schwupps läuft das grml.

Der Rest ist schnell erzählt: LVM bauen, Filesysteme anlegen, Daten zurück-rsyncen, chroot ins frisch restorete System, IP-Adresse anpassen, /boot/grub nach /boot/woody-grub umbenennen, /boot/grub-backup zurückschieben, "aktuellen" grub neu installieren, booten und Produktivbetrieb aufnehmen. Das grml bleibt da für zukünftige Aktionen liegen, mit dem aktuellen Grub lässt es sich ja auch nach Anpassung des Default-Wertes in der menu.lst kurzfristig booten.

Trackbacks

node-0.mneisen.org on : PingBack

Unfortunately, the contents of this trackback can not be displayed.

node-0 on : Einstimmiges Votum

Show preview
Es freut mich immer, wenn ich mit einer von mir geäußerten Meinung zumindest nach einiger Zeit nicht mehr alleine dastehe. Nicht, dass ich für meine Positionen nicht zu kämpfen bereit bin oder glaube, man könne die Wahrheit per Mehrheitsbeschluss...

Zugschlusbeobachtungen on : grml als eigenes Rescuesystem

Show preview
In Mietserver-Recovery mit veraltetem Rescuesystem habe ich beschrieben, wie man grml aus dem komprimierten Image von einer Festplatte booten kann, was zum Beispiel für Rescue-Zwecke an einem Server ohne direkt zugängliche Konsole sehr praktisch sein ka

Comments

Display comments as Linear | Threaded

-thh on :

Tja, die Geschichte mit dem ab 0 zählenden grub hat mich am 23. auch erwischt. Ich hab nur ... etwas länger gebraucht, um das zu checken. seufzelchen

-thh, "das Szlauszaf kann niszt zählen"

Jan on :

kann es evtl sein, daß du die /boot -Partition meinst? -- die / hast du doch sicher auch encryptet im LVM liegen.

Ich habe bei mir aktuell eher noch das Problem, daß beim Boot des fertigen Systems die Passphrase an die Konsole muß. Das würde ich ungern über eine Serielle (oder wie bei mir ein KVM over IP (auf anforderung)) tun. Darum spiele ich gerade an der initrd, die das Netz rudimentär hochbringt und einen dropbear startet, bevor das system den pvscan macht.

Marc 'Zugschlus' Haber on :

Nein. Ein cryptofilesystem hat auf einem dauernd laufenden System nur sehr eingeschränkt Sinn. Auf meinen Arbeitsplatzrechnern, deren Normalzustand "aus" ist, sind die Platten verschlüsselt, auf den Servern nicht.

Add Comment

Markdown format allowed
Enclosing asterisks marks text as bold (*word*), underscore are made via _word_.
Standard emoticons like :-) and ;-) are converted to images.
E-Mail addresses will not be displayed and will only be used for E-Mail notifications.
Form options