Hetzner - DokuWiki

Tutorial: Rescue-Partition? auf Entry-Server?

Original erstellt von Alexander Balzer, Henning Möller und Viktor Pankraz im Hetzner-Forum. Ins Hetzner-Wiki übernommen von Benutzer "sNOOBy"

Vorbemerkungen

Sinn und Zweck

Eine Rescue-Partition am Ende der Festplatte im Entry-Server? hat natürlich nur bedingt Sinn. Ist der Rechner nicht mehr bootfähig, dann nützt auch diese Rescue-Partition? nichts. In dem Fall kann nur der Support oder das von Hetzner in Aussicht gestellte externe Rescue-Image?, bootfähig über den Robot, weiterhelfen. Bis dahin aber kann man mit Hilfe dieser Lösung regelmäßige Backups des Gesamtsystems machen und jeden beliebigen Zeitpunkt wiederherstellen - ohne jedesmal vom Basis-Image? ausgehen zu müssen.

Ausgangspunkt

Ausgangspunkt ist ein Hetzner-Entryserver? mit Basisimage. Das Ganze funktioniert nur, solange das laufende System noch auf die Swap-Partition? passt, auf der es im Laufe des Prozesses "zwischengelagert" werden muss.

Zielsetzung und grobes Vorgehen

Ziel ist es, aus der Standard-Partitionierung

eine erweiterte Partitionierung

zu machen.

Da es nicht möglich ist, /dev/hda2 zu verkleinern, solange es gemountet ist, müssen wir zunächst unsere Swap-Partition zu einem temporären Rescue-System umfunktionieren. Zum Umpartitionieren benutzen wir dann das Paket parted.

Auf dem Basisimage von Hetzner liegt bereits ein vorkompiliertes Kernel-Paket, das alle benötigten Treiber für die Hardware enthält. Wir verwenden genau diesen Kernel, also den gleichen, der bereits auf dem Production-System? läuft.

Quellen

Das Tutorial ist aus verschiedenen Quellen zusammengesetzt und mit eigenen Ideen angereichert:

  1. Installation eines Rescue-Systems auf der Swap-Partition
  2. Verwendung von debootstrap
  3. Kernel-Installation nach debootstrap

Warnung und Haftungsausschluss

Diese Prozedur ist sicher nicht ungefährlich und kann unter Umständen dazu führen, dass der Server nicht mehr bootet.

Davon zu sprechen, dass nur Gurus diese Anleitung verwenden dürfen, wäre Unsinn. Normale Root-Server-Kunden? gehören in der Regel vermutlich nicht in diese diese Kategorie. Die Benutzung von fdisk und ähnlichen Tools wird allerdings als bekannt vorausgesetzt.

Wird die Prozedur korrekt durchgeführt, sollten alle Daten auf der Production-Partition erhalten bleiben. Aber selbstverständlich übernimmt NIEMAND IRGEND EINE GARANTIE dafür, außer:

     If you break it, you own both parts.

(Zu gut deutsch und frei übersetzt etwa: "Wenn du dein System kaputt machst, musst du selber sehen, wie du damit weiter klar kommst.")

Auf jeden Fall sollte man die ganze Prozedur zuerst auf einem lokalen Rechner mit Zugriff auf die Konsole üben.

Ausblick

Mit parted kann man natürlich auch weitergehende Umpartitionierungen? vornehmen, also z.B. an Stelle der primären Partition /dev/hda2 eine extended Partition mit einer beliebigen Aufteilung in logische Laufwerke anlegen. In dem Fall muss man anschließend die Daten von der Swap-Rescue-Partition /dev/hda1 wieder in die dann passenden logischen Laufwerke zurück kopieren. Das ist aber nicht Gegenstand dieses Tutorials.

Schritt-für-Schritt-Anleitung

Swap deaktivieren:

~$ swapoff /dev/hda1

Swap-Partition in Boot-Partition umwandeln:

Wir verwenden fdisk, um zunächst die Swap-Partition zu löschen und anschließend eine neue, bootfähige Linux-Partition zu erstellen. Dabei lassen wir Zylinder 1 frei, die bootfähige Partition beginnt also erst bei Zylinder 2! Nach der Änderung der Partitionierung das Zurückschreiben der Patitionstabelle nicht vergessen.

~$ fdisk /dev/hda

Reboot, um die Partitionstabelle zu aktualisieren:

~$ reboot

Die neue Partition formatieren:

~$ mke2fs /dev/hda1

Verzeichnisse zum Mounten der beiden Partitionen erzeugen:

~$ mkdir /production
~$ mkdir /swaprescue

Mounten der Partitionen:

~$ mount /dev/hda2 /production
~$ mount /dev/hda1 /swaprescue

Production-System kopieren:

Das komplette Production-System auf die neue Partition kopieren. Dies funktioniert nur, wenn das System nicht größer ist als der Platz auf der Swap-Partition, also ungefähr 1 GB.

~$ cp -a /production/. /swaprescue/.

Root ändern:

~$ chroot /swaprescue

fstab anpassen:

Beim Booten des /swaprescue Systems muss die neue Partition /dev/hda1 als Root-Partition / gemountet werden. Gleichzeitig muss der Verweis auf die Swap-Partition, der ja auch noch auf /dev/hda1 verweist, entfernt werden.

~$ vi /etc/fstab

lilo.conf ändern:

In der lilo.conf des /swaprescue Systems muss die Zeile "root=/dev/hda2" in "root=/dev/hda1" geändert werden.

~$ vi /etc/lilo.conf

lilo neu schreiben:

~$ lilo

Reboot ins /swaprescue System:

Vorher muss die chroot Umgebung verlassen werden.

~$ exit
~$ reboot

Sources für parted hinzufügen:

~$ echo "deb http://www.fs.tum.de/~bunk/debian woody/bunk-2 main contrib non-free" >> /etc/apt/sources.list
~$ echo "deb-src http://www.fs.tum.de/~bunk/debian woody/bunk-2 main contrib non-free" >> /etc/apt/sources.list

parted (1.6.9) installieren:

~$ apt-get update
~$ apt-get install parted

  No Implementation: This ext2 file system has a rather
 strange layout!  Parted can't resize this (yet).

Umpartitionierung:

Mit parted wird nun die Production-Partition hinten um 500 MB (man kommt theoretisch auch mit 200 MB aus) verkleinert. Im so frei gewordenen Bereich wird eine neue, bootfähige Partition erzeugt und auch gleich formatiert.

Achtung: Bei parted ist Vorsicht geboten. Anders als fdisk führt parted alle Änderungen ohne Rückfrage sofort aus.

~$ parted /dev/hda
   |  print
   |  resize 2  -500
   |  print
   |  mkpartfs primary ext2  -0
   |  quit

(Die Befehle "print" bis "quit" sind keine Shell-Befehle?, sie werden innerhalb von parted eingegeben.)

lilo neu schreiben:

Sicherheitshalber wird lilo hier nochmal neu geschrieben, obwohl normalerweise nicht wieder in dieses /swaprescue System hinein gebootet werden muss. Aber man kann ja nie wissen...

~$ lilo

Rescue-Partition mounten:

~$ mkdir /rescue
~$ mount /dev/hda3 /rescue

/etc/apt/sources.list bereinigen:

An dieser Stelle sollte sicherheitshalber die weiter oben zu /etc/apt/sources.list hinzugefügte Quelle für parted wieder entfernt werden.

~$ vi /etc/apt/sources.list

debootstrap und einige Hilfspakete installieren:

~$ apt-get update
~$ apt-get install debootstrap ftp binutils

Grundinstallation:

~$ debootstrap --arch i386 woody /rescue ftp://ftp.de.debian.org/debian

Konfiguration kopieren:

Einige grundlegende Konfigurationdateien übernehmen wir einfach aus der aktuellen Installation und passen sie zum Teil später an.

~$ cd /rescue/etc
~$ cp /etc/fstab .
~$ cp /etc/lilo.conf .
~$ cp /etc/network/interfaces network
~$ cp /etc/resolv.conf .
~$ cp /etc/hostname .

Root ändern:

~$ chroot /rescue

fstab anpassen:

In der fstab auf dem /rescue System muss /dev/hda3 auf / gemountet werden. Sinnvollerweise kann man auch gleich /dev/hda2 (die Production-Partition ) auf /production mounten.

~$ mkdir /production
~$ vi /etc/fstab

Tastatur konfigurieren:

Ob das notwendig ist? Jedenfalls haben wir eine quertz-Tastatur mit deutschem Layout eingestellt.

~$ dpkg-reconfigure console-data

Zeitzone, Benutzer und apt konfigurieren:

~$ base-config

Locales installieren:

Wir haben DE-de(Euro) installiert.

~$ apt-get install locales

Kernel-Installation? vorbereiten:

~$ apt-get install initrd-tools

mkinitrd.conf anpassen:

Hier muss explizit die Zeile "ROOT=probe" durch "ROOT=/dev/hda3" ersetzt werden.

~$ vi /etc/mkinitrd/mkinitrd.conf

Proc mounten:

~$ mount /proc /proc -t proc

Kernel-Image? in die chroot Umgebung kopieren:

In /usr/src/ liegt (bei unserem Image) nur ein Debian-Package (deb) mit einem 2.4.20er Kernel.

~$ exit

~$ cp /usr/src/kernel-image....deb /rescue/root
~$ chroot /rescue

Kernel installieren:

Es braucht kein Bootloader installiert zu werden. Die entsprechende Rückfrage ist mit "No" zu beantworten.

~$ dpkg -i ~/kernel-image....deb

ssh installieren:

~$ apt-get install ssh

Rescue-Partition? bootfähig machen:

Jetzt muss noch dafür gesorgt werden, dass von /dev/hda3 gebootet wird. Gleichzeitig muss man die Zeilen für "image=/vmlinuz-2.4.18" (gegen Ende der Datei) auskommentieren, weil das sonst beim Schreiben von lilo zu Fehlermeldungen führt.

~$ vi /etc/lilo.conf

Rescue-System booten:

~$ lilo
~$ exit
~$ reboot

Swap-Partition? wieder anlegen:

Mit fdisk wird nun die Partition 1 wieder gelöscht und durch eine Swap-Partition (Typ 82) ersetzt. Zurückschreiben der Partitionstabelle nicht vergessen!

~$ fdisk /dev/hda
~$ reboot

Swap-Partition? formatieren:

~$ mkswap /dev/hda1

lilo.conf des Production-Systems? anpassen:

Auch in dieser Datei muss man die Zeilen für "image=/vmlinuz-2.4.18" auskommentieren.

~$ vi /production/etc/lilo.conf

Reboot ins Production-System:

~$ lilo -C /production/etc/lilo.conf
~$ reboot

Production-System? bereinigen:

Außerdem wird für spätere Verwendung noch ein Mount-Point für das Rescue-System angelegt.

~$ rmdir {/production,/swaprescue}
~$ mkdir /rescue

Rescue-Partition in die fstab eintragen:

Um das Mounten der Rescue-Partition zu vereinfachen, kann man noch die folgende Zeile in die fstab eintragen. Damit kann die Rescue-Partition im Bedarfsfall einfach mit "mount /rescue" gemountet werden.

/dev/hda3 /rescue ext2 noauto 0 0

Geschafft!

Um nun vom Production- ins Rescue-System zu wechseln, muss man folgendes machen:

~$ mount /dev/hda3 /rescue
~$ lilo -C /rescue/etc/lilo.conf
~$ reboot

Um vom Rescue- wieder ins Production-System zu booten, gibt man folgendes ein:

~$ lilo -C /production/etc/lilo.conf
~$ reboot

Das war's. Viel Erfolg.