64bit => 32bit Debian Etch

[millo]

Hi,

leider macht ein 64Bit System von mir Probleme, sodass ich wieder auf 32bit zurück konvertieren möchte.
Da der Rechner leider nur im RZ steht und nichts außer einem Ethernetanschluss verfügt, möchte ich die Migration "live" durchführen.

Derzeitiger Plan:

Swap auf XFS formatieren, debootstrap 32bit Debian, alle Einstellungen, Kernel, bla blub, davon booten (wenn das funktioniert hätte man den kritischen Teil überstanden), hiervon aus nun die Platten entsprechend partitionieren, ins zweitneue System hineinbooten, swap plätten, nochmal reboot - fertig.

Irgendwelche Einwände?

Danke!

[skander01]

Sag mal... stellt dein Provider kein s.g. Rescue-Mode zur Verfügung?

Ich hab meinen Root bei Hetzner und dort kann ich jederzeit den Rescue-Mode starten um den Rechner von einen unabhängigen System zu bedienen. Damit wären auch solche Aktionen problemlos möglich.

Und willst du das nicht erst daheim probieren (vorausgesetzt du hast entsprechend Traffic)?

Ich habs so gemacht:
- VMWare (frei erhältliche Version) installiert und entsprechende Partitionen angelegt (1:1 wie auf dem Root PLUS eine extra für ein eigenes Linux System)
- minimales Linux (in meinem Fall Debian) installiert
- sowohl auf dem Root als auch auf der VMWare Maschine rsync installiert
- mittels rsync über ssh ALLES auf die VMWare Maschine in eine eigene Partition gezogen (das hat gedauert ;)
- Bootmanager angepasst, damit das gespiegelte System gebootet werden kann (in diesem Fall SuSE 10.1)
- System gebootet
- Mittels VmWare nen Snapshot gezogen, damit bei evtl. Fehlern im Ablauf nicht das gesamte System erneut gespiegelt werden muss
- Einstellungen für die VMWare Machine vorgenommen (Netwerkkarten eingerichtet und mit LAN IP versehen)
- rumgefummelt

Wenn du ein paar Anleitungen zu Rsync-Spiegelungen brauchst, dann meld dich bei mir.


Gruss,

Skander

[aquajo]

Ich habe zwar noch nicht 64Bit ->32 Bit gemacht, aber u.A. zum Umpartitionieren den Umweg über einen formatierten Swap genommen.
Geht ganz gut, mann muss nur aufpassen die fstab, Netzwerkkonfig und Bootloader richtig zu konfigurieren.

[skander01]

Naja.. ein ganzes downgrade ist dann schon ein bissl mehr..

Ich geh auf nummer sicher und sicher erst alles (nach dem o.g. Schema). Dann kann man auch getrost ein komplett neues System über den Provider aufsetzen.

Dann nur die gewünschten Daten wieder hochziehen (evtl auch über rsync).

Auch falls was schiefgehen sollte kann man so noch auf das Original-System zurückkehren (bei entsprechender Partitionierung).

[millo]

Operation erfolgreich ;)
Hat eigentlich alles genauso geklappt wie ich mir das gedacht hatte. :)

Bzgl Rescue System:

Der Server steht im RZ (Co-Location), und wie gesagt ohne KVM / Rescue System, usw.
Aber bei Gelegenheit werde ich zumindest ein Rescue System mal einrichten...

[skander01]

Ohne Rescue System... hm... das nenn ich Mutig ;)
FROH, dass ich Zugriff auf ein Rescue System hatte... einfach die Grup-Config umgestellt und wieder neu gestartet...

Und da war wieder mein altes System mit altem Kernel ;)

[millo]

Generell braucht man kein Rescue System. Wenn das System produktiv läuft (tat es bis jetzt nicht), "darfst" du mehr oder weniger nicht rebooten oder irgendwelche Sachen ausprobieren.
Wenn sich dein Server aufhängt, liegt es meist an der Hardware als am Server selbst - da hilft ein Rescue System höchstens zur Fehleranalyse, aber wer kann sich schon eine mehrstündige Downtime erlauben. ;)

[dtdesign]

Generell braucht man kein Rescue System.

Auch wenn deine Folgeargumentation schlüssig und korrekt ist, so ist diese Aussage trotzdem falsch.

Wenn das System produktiv läuft (tat es bis jetzt nicht), "darfst" du mehr oder weniger nicht rebooten

Kernelupdates, Updates der libc, etc. Alles sehr gute Gründe für einen sofortigen Neustart.

oder irgendwelche Sachen ausprobieren.

Full ACK.

Wenn sich dein Server aufhängt, liegt es meist an der Hardware als am Server selbst - da hilft ein Rescue System höchstens zur Fehleranalyse...

Naja, es gibt genug Gründe, Fehler im Kernel können schnell mal das System mit einem freundlichen "Kernel Panic" abschießen. Aber meist ist tatsächlich die Hardware schuld (wenn man von dem "50cm-vor-dem-Bildschirm"-Fehler absieht *g*).

Rescue-Systeme ermöglichen es auch, ein Backup zurück zu spielen oder sich Full-Backups zu ziehen.

aber wer kann sich schon eine mehrstündige Downtime erlauben. ;)

Richtig, aber im zweifelsfalle ist dies nicht relevant. Lieber ein paar Stunden Downtime in Kauf nehmen um damit das System sicherer und stabiler zu machen. Wenn dein Server 2-3 Mal gehackt wirst waren es mal deine Kunden.

Absolute Aussagen zu machen ist meist relativ problematisch :)

Gruß
dtdesign

[skander01]

So seh ich das auch.

Bei mir ist es zur Zeit mit der Downtime net so schlimm. Ich hoste lediglich ein paar Clan-Pages und 2 eigene Game-Server. Somit ist das net so das prob.

Aber ich hatte auch schon ein paar mal das Prob, dass sich das System mit ner Kernel-Panic aufgehängt hat.

Das Recue Syetem ist bei Problemen während des Hochfahrens des Systems sehr hilfreich. Ein 'dummes' Beispiel war die Installation von ISPConfig, welche für das Betreiben der Server-Software ein Passwort beim Starten benötigt (habe ich absichtlich eingerichtet).

Was ich nicht bedacht habe... Wird ISPConfig nun beim Booten gestartet, wartet jedoch auf die Passwortreingabe und das noch BEVOR der SSH-Daemon gestartet wird, dann wartet das System ewig an dieser Stelle...

Glücklicher weise habe ich hier Zugriff auf ein Rescue Syetem gehabt und konnte so erstmal das Startskript der ISPConfig Server Software aus den Runlevels entfernen.

Bei Bedarf starte ich das dann einfach manuell.