Server-Foren > Server - HowTo's

Debian amd64 auf Root-Server installieren

(1/2) > >>

ingoj-wbs:
Nach der Auslieferung des Rootserver XL von EUserv mit vorinstalliertem Debian 3.1, gab es das Problem, dass der Rechner auf amd64 statt i386 (also 64bit statt 32bit) laufen sollte, um eine leichte Austauschbarkeit der zu benutzenden Xen Domains mit einem anderen Server gewaehrleisten zu koennen.

Dummerweise stellt EUserv bis dato nur ein 32bit Rescue System zur Verfuegung, was die Migration von i386 auf amd64 nicht unbedingt einfacher macht. Sei's drum...

Hier nun ein kleines HowTo fuer die Migration auf ein Debian amd64 System:

Voraussetzungen:
- ein vorhandenes (externes) Debian amd64 System
- eine zusaetzliche Platte oder zumindest Partition erleichtert das Leben mitunter
- gute, starke Nerven

Vorbereitungen:
- ein Chroot fuer amd64 bzw. i386 anlegen: in das amd64 Verzeichnis kann man sein externes amd64 hineinkopieren und entsprechend vorkonfigurieren. In das i386 Verzeichnis kommt spaeter das (originale) 32bit System hinein, da man dies spaeter im Rescue System brauchen kann.

Migration:
- kopieren des externen amd64 Systems in das amd64 Verzeichnis, z.B. /amd64.
- Rescue System booten
- entsprechende Partition mounten
- i386 und amd64 austauschen: alle Daten des Rootfs ("/") in das i386 Verzeichnis verschieben (mit Ausnahme des amd64 Verzeichnisses und anschliessend den Inhalt des amd64 Verzeichnisses in das ehemalige 32bit rootfs kopieren bzw. verschieben.
- den Bootloader mit den neuen Kernelversion bestuecken
- das Editieren von /etc/fstab und /etc/network/interfaces nicht vergessen! (eventuell die Version aus dem i386 Verzeichnis benutzen/kopieren)
- bei Bedarf aus dem Chroot der gemounteten Partition heraus den Bootloader neu schreiben
- eventuell die Host Keys aus dem alten System (i386) ins neue (amd64) kopieren (/etc/ssh/ssh_host_*)
- Normal booten

Mit viel Glueck bootet nun das amd64 System. Das ist in etwa die Kurzversion meiner Odyssee der vergangenen Tage.
Einige Stolpersteine gibt es zu beachten:
- die erste Platte muss ueber eine Partition mit einem bootable Flag verfuegen.
- grub hat in verschiedenen Versionen offenbar unterschiedliche Pfade in der menu.lst fuer die kernel und initrds: statt /boot/vmlinuz... bedarf es in neueren Versionen nur noch /vmlinuz..., also ohne vorangestellten /boot. Das ist vielleicht ein Unterschied zwischen der Sarge Variante und der Etch Version, die ich benutzt habe.
- bei Verwendung eines Raids (RAID1/mirroring) sollte man bei einer Config bleiben und nicht einzelne Partitionen aus dem Raid herausnehmen.
- bei SMP Rechnern wie dem Rootserver XL sollten keine Optionen wie noapic oder acpi=off in der Bootloader Config sein
- bei der Verwendung von XFS auf dem rootfs sollte keine mount Option "errors=remount-ro" gesetzt sein

WARNUNG:
Zum Schluss noch ein paar warnende Worte: Die Migration sollte nicht bei einem produktiven System angewandt werden. Es koennen Daten verloren gehen und die Downtime kann laenger als geplant andauern.
Und sowieso ist das ganze auf eigene Gefahr! Wer sowas macht, sollte wissen was er tut und vor allem auch, wie er sich *selber* helfen kann.

Die Migration auf amd64 ist auf einem entfernt stehenden Rechner sicherlich kein Pappenstiel, wenn man keine serielle Console zum Debuggen hat. Wer noch nie remote Systeme installiert hat (rescue system + debootstrap) sollte am besten gleich die Finger davon lassen. Es hoert sich in diesem kleinen HowTo sehr viel leichter an, als es letztendlich in Wirklichkeit war!

Es gab sicherlich noch die eine oder andere Schwierigkeit bei unserer Migration auf amd64. Inzwischen laeuft der Rootserver XL aber zu unserer Zufriedenheit mit Debian Etch amd64 und Xen mit gemirrorten Partitionen im Raid1 und LVM fuer die Xen DomUs... :-)

Tech-EUserv1:
Hallo,

klasse HowTo.

Zum Thema Rescue-System:
Die Bereitstellung des Rescue-Systems ist abhängig vom installierten
OS, d.h. ist ein 32Bit OS installiert wird ein 32Bit Rescue gebootet,
ist ein 64Bit System installiert, wird ein 64 Bit Rescue gebootet.

Hintergrund ist die Möglichkeit, ohne Probleme in das installierte
System zu wechseln.

Matthias

ingoj-wbs:

--- Zitat von: "Tech-EUserv1" ---Hallo,
klasse HowTo.

--- Ende Zitat ---


Danke, aber ich hab sicherlich was vergessen. Fuer eine Punkt-fuer-Punkt Anleitung fehlte mir halt auch die Zeit... das System sollte schnellstmoeglich in Betrieb gehen und wenn die Kollegen im Hintergrund unruhig werden, wann denn nun der neue Server verfuegbar ist, bleibt fuer sowas halt wenig (=keine) Zeit... ;)


--- Zitat ---
Zum Thema Rescue-System:
Die Bereitstellung des Rescue-Systems ist abhängig vom installierten
OS, d.h. ist ein 32Bit OS installiert wird ein 32Bit Rescue gebootet,
ist ein 64Bit System installiert, wird ein 64 Bit Rescue gebootet.

--- Ende Zitat ---


Ja, das hab ich ja auch gemerkt... ;)

--- Zitat ---
Hintergrund ist die Möglichkeit, ohne Probleme in das installierte
System zu wechseln.
--- Ende Zitat ---


... das Problem ist halt nur, wenn jemand nachtraeglich ein anderes System installiert, dann macht genau dieses Verhalten die ganze Sache nahezu unmoeglich, sprich: er kann halt eben nicht mehr ohne Probleme in das installierte System wechseln.

Da, denke ich, ist es einfacher, dem User die freie Wahl des Rescue Systems zu lassen. Wenn er das falsche anklickt, wird er es schon frueh genug beim chroot merken. Eventuell generiert man dadurch ein paar zusaetzliche Supporttickets, aber da koennte auch schon ein entsprechender Hinweis auf der Rescue System Seite Linderung verschaffen.
Andererseits gibt man den Kunden mit der freien Auswahl des Rescue Systems entsprechende Freiheit in die Hand, das System installieren zu koennen, dass der Kunde wuenscht, was auf einer 64bit CPU meistens wohl auch bedeutet, dass der Kunde ein 64bit Betriebssystem haben moechte. ;)
Aber das Problem wird sich ja wohl eh mit dem Release von Etch in Wohlgefallen aufloesen....

Wie auch immer: die eigentliche Schwierigkeit bestand auch nicht im fehlenden 64bit Rescue System, sondern darin, dass man ins Blaue hinein raten muss, wenn etwas beim Bootloader schiefgeht. Der Rest ist dann eher Fleissarbeit. ;)

White2001:
das mit grub und dem /vmlinuz Pfad wird meistens adners gelöst.

Das Problem leigt darin das grub einmal die boot partition direkt zugeift und einmal im gebotetetn system der pfad aber anders ist /boot

lösung: in den meisten fällen liegt in /boot nen symlink auf sich selbst.
ln -s . /boot/boot

wenn man den ausversehen löscht, sucht man auch sehr lange :)

NightEagle:
Hm,

wenn Du hier schon so eine sehr "vage" Anleitung hineinstellst, solltest Du das auch im Interesse der anderen
User ausführlich machen, und nicht nur in Stichpunkten, so ist das für mich kein HowTo, sondern ein
paar dahin geschriebene Worte ohne Inhalt.

Gruß, NightEagle

Navigation

[0] Themen-Index

[#] Nächste Seite