Desaster-Recovery: Bootpartition gelöscht – Tools & Tipps

Hallo Leser,
vor einigen Wochen wurde ich von einem Freund kontaktiert. Dieser hatte aus versehen ein „dd“ auf seine Bootpartition ausgeführt, sodass alle Daten mit einer Kubuntu-ISO überschrieben wurden. In diesem Blogartikel möchte ich ein paar hilfreiche Tipps & Tools für eine solche Desaster-Recovery vorstellen.

1. Nicht am Livesystem frickeln

Wenn man nicht genau weiß, wie man das Problem behebt oder wenn man sich nicht sicher ist, ob Komplikationen entstehen, ist es immer besser an einer Kopie der Daten zu arbeiten. Da es sich hier um ein Festplattenproblem handelt, erstellen wir einfach eine Kopie:

sudo dd if=/dev/sda of=/mnt/extern/sda.img bs=64K

Dafür muss eine mindestens gleichgroße Festplatte vorhanden und in „/mnt/extern“ gemountet sein. Je nach größer der Festplatte kann dieser Vorgang einige Stunden dauern. Den Fortschritt kann man sich mit folgenden Tools anschauen:

  • iotop : Zeigt Lese-/Schreibgeschwindigkeiten an.
  • watch du -sm /mnt/extern/sda.img : Zeigt alle 2 Sekunden die Größe von /mnt/extern/sda.img an.

Zusätzlich sollte man sich noch Informationen über die Partitionen speichern:

sudo fdisk -lu /dev/sda > /mnt/extern/sda.fdisk

Nachdem das Image erstellt wurde, kann man dieses auf ein anderes System übertragen und dort seine Fixes ausprobieren. Sollte man dabei einen Fehler machen, so kann man entweder die Festplatte erneut klonen oder ein Backup des Images einspielen.

2. Image mounten mit losetup, kpartx & cryptsetup

Mein Kumpel setzt auf ein LVM-Setup, welches zuvor mit Hilfe von Cryptsetup verschlüsselt wird. Mit dem Tool „losetup“ kann man Images an ein Loopback-Device binden.

Eine Übersicht aller aktiv genutzten Loopback-Devices bekommt man mit:

> losetup --all
/dev/loop0: [65027]:685167 (/media/truecrypt1/Backup/sda.img)

Um das Image einzubinden reicht der folgende Aufruf:

losetup -f --show /mnt/extern/sda.img
/dev/loop0

Dieser Befehl bindet das Image an das nächst freie Loopback-Device. Möchte man später das Loopback-Device „unmounten“, so nutzt man diesen Aufruf:

losetup -d /dev/loop0

Als nächstes können wir uns die verschiedenen Partitionen einbinden lassen. Dazu werden wir das Programm „kpartx“ nutzen. Dieses schaut in die Partitionstabelle und erstellt pro Partition ein Mapping:

> sudo kpartx -av /dev/loop0 
add map loop0p1 (254:4): 0 389120 linear /dev/loop0 2048
add map loop0p2 (254:5): 0 976381952 linear /dev/loop0 391168
> ls /dev/mapper/loop0p* 
lrwxrwxrwx 1 root root 7  4. Okt 22:45 /dev/mapper/loop0p1 -> ../dm-4
lrwxrwxrwx 1 root root 7  4. Okt 22:45 /dev/mapper/loop0p2 -> ../dm-5

Ab jetzt kann man auf die Bootpartition (loop0p1) zugreifen bzw. die verschlüsselte Partition (loop0p2) entschlüsseln:

sudo cryptsetup luksOpen /dev/mapper/loop0p2 recovery

Ab hier sollte sich LVM um das automatische Mappen der Logical Volumes kümmern. Nach dem Mounten der entsprechenden LVs kann man z.B. kleine Änderungen am System durchführen, oder Logdateien durchforsten.

3. System in VirtualBox starten

Um leichter Neustarts zu simulieren, werden wir das System in VirtualBox starten. Da VB keine „Raw“-dd-Festplattenimages von Haus aus unterstützt, müssen wir eine Art „Symlink“ erstellen:

VBoxManage internalcommands createrawvmdk -filename /tmp/sda.vmdk -rawdisk /dev/loop0

Jetzt kann man in VirtualBox eine neue virtuelle Maschine aufsetzen und /tmp/sda.vmdk als Festplatte auswählen.

4. Ein Chroot aufbauen

Bootet man nun eine Live-CD in dieser VM, so kann man alle möglichen Fixes durchprobieren. So wird man wahrscheinlich, wie unter 2. beschrieben, die Festplatte in der virtuellen Maschine mounten. Da wir langsam das Problem beheben wollen, müssen wir irgendwie in das alte System reinkommen. Dazu werden wir uns ein Chroot aufbauen:

mkdir /tmp/chroot
mount /dev/mapper/lvm-root-partition /tmp/chroot
mount /dev/mapper/loop0p1 /tmp/chroot/boot
mount /dev/mapper/lvm-home-partition /tmp/chroot/home
mount -o bind /dev/ /tmp/chroot/dev
mount -o bind /proc/ /tmp/chroot/proc
chroot /tmp/chroot

„lvm-root-partition“ bzw. „lvm-home-partition“ müssen entsprechend ersetzt bzw. erweitert werden.

5. Grub reinstallieren

Wir arbeiten immer noch in der VM. Zunächst müssen wir die Daten in „/boot“ los werden. Dazu sollte ein einfacher Löschbefehl ausreichen:

rm -rf /boot && mkdir /boot

Alternativ kann das Dateisystem neu aufsetzen. (Angenommen: sda1 ist /boot)

umount /boot
mkfs.ext4 /dev/sda1
mount /dev/sda1 /boot

Danach müssen wir in der /etc/fstab die UUID der Partition erneuern. Die neue ID finden wir mit Hilfe von „blkid“ heraus:

blkid /dev/sda1 
/dev/sda1: UUID="9baa4766-b925-4e6a-9f1f-160b01d53dec" TYPE="ext4" PARTUUID="000e3dbd-01" 

Nun editiert man die „/etc/fstab“ und ersetzt die alte UUID durch die neue. Der alte Eintrag sieht wahrscheinlich so ähnlich aus:

# UUID=c000432b-9950-4e5e-8379-dafdc2f9cc72 LABEL=boot
/dev/sda1 /boot ext4 rw,relatime,data=ordered 0 2

Sind diese Schritte getan, kann man Grub neu einrichten. Unter Arch Linux sollte es ausreichen, die Pakete „grub“ und „linux“ erneut zu installieren.

sudo pacman -S grub
sudo pacman -S linux

Zunächst werden die Grub-Pakete installiert. Daraufhin wird der Kernel neu installiert, wobei die entsprechenden Grub-Einträge neu erstellt und die benötigten Änderungen ins /boot geschrieben werden.

Jetzt sollte ein Neustart der VM ohne Live-CD zum Boot des Systems führen. Andernfalls wiederholt man die vorherigen Schritte bis man das Problem behoben hat.

6. Mit Grub eine Rootshell erhalten

Sollte man bei der Arbeit mit dem System nach Benutzerpasswörtern gefragt werden, welche man nicht hat, so kann man folgenden „Hack“ verwenden. Während dem Grub-Bootmenü drückt man „e“ um den Editor aufzurufen.

Dann sucht man sich den entsprechenden (meistens 1.) Menüeintrag und darin die Zeile die mit „linux“ anfängt. An diese hängt man folgendes an:

init=/bin/bash

Mit „F10“ speichert man diese temporäre Konfiguration. Nach dem Bootvorgang wird man direkt in eine Root-Shell eingeloggt, aus welcher man das Root bzw. Benutzerpasswort bearbeiten kann.

Fazit

Nicht immer muss man ein Linux-System nach einem Fehler komplett neu aufsetzen. Oft kann man den einen oder anderen Fehler ausbügeln. Ich hoffe, das ich einige nützliche Tools vorstellen konnte.

~Sebastian