Ich wollte aus verschiedenen Gründen meiner Linux-Installation mal einen kompletten Neustart gönnen und Kubuntu Karmic Koala frisch aufsetzen. Dabei wollte ich allerdings vorzugsweise darauf verzichten mein aktuell 83 GB schweres Home-Directory komplett aus dem Backup wieder einspielen zu müssen. Gedacht, ... fast getan. Backup wurde natürlich vorher gemacht (ich bin ja nicht wahnsinnig. Jedenfalls nicht wesentlich mehr, als üblich. Außerdem hatte jemand in der näheren Umgebung letztens erst den Fall, dass sämtliche Daten zwar noch da, aber dank Festplattenverschlüsselung mit kaputtem Keystore nicht mehr zugreifbar waren. Das wollte ich mir natürlich ersparen.
Erstmal dazu, wie meine Platte grob aussieht:
/dev/sda
|
+---sda1 (/boot)
+---sda2 (dm-crypt-Volume)
|
+---ec_root (/)
+---ec_swap (swap)
+---ec_home (/home)
Soweit, so unpraktisch. Speziell /home sollte unbedingt erhalten bleiben. Erster Anlauf: ganz naiv den Installer gestartet und geschaut, was er so erkennt. Klappt natürlich nicht. Der sieht sda2 und interessiert sich kein bischen für die Innereien. Ok, zweiter Anlauf: Situation herstellen, die dem Installer erlaubt die Innereien zu erkennen:
cryptsetup luksOpen /dev/sda2 sda2_crypt
lvm vgchange -a y
Das erste öffnet das verschlüsselte Volume, das zweite aktiviert die darin enthaltene Volume Group und alle logischen Volumes innerhalb dieser. Das ganze macht man am besten in einer zweiten Konsole, während der Installer gerade auf Nutzereingaben wartet (bspw. wenn er sich grad aufregt, dass er kein Netz findet). Danach kann man die Installation gemütlich weiterlaufen lassen und der Installer wird beruhigt die Volumes erkennen, so dass man in der manuellen Partitionierung (alles andere wäre Unsinn) alles entsprechend wieder zuweisen kann, wie es sein soll.
Mir ist hier noch ne Kleinigkeit unangenehm aufgefallen: sda2 wird aus irgendeinem Grund als Swap eingestuft. Aus Sicherheitsgründen habe ich das komplett rausgenommen (also auch nicht als Crypto-Volume definiert), was zur Folge hatte, dass hinterher etwas Handarbeit angesagt war.
Wenn die Installation durchgelaufen ist (auch das kann ein Problem sein, wenn das CD-Laufwerk auf einmal I/O-Error wie Kekse verteilt...), dann muss man noch einige kleinere Anpassungen machen um das System bootfähig zu machen. Was ist das Problem? Dadurch, dass das Crypto-Volume von Hand geöffnet wurde und der Installer so nichts davon weiß, fehlt der entsprechende Eintrag in der /etc/crypttab des frisch installierten Systems. Das wiederum führt dazu, dass das initrd nichts über die Verschlüsselung weiß und nicht nach dem Passwort fragt, was wiederum den Bootprozess einfach stillstehen lässt. Blöd. Eine Lösung muss her...
Im Prinzip isses einfach: man macht das System von Hand bootfähig. Man mountet noch im laufenden Installersystem /dev und /proc mittels -o bind nach /target/dev und /target/proc (/target ist der Punkt, wo der Installer die Platte einhängt. Wenn nicht: einfach selbst machen), wechselt mittels chroot /target ins installierte System, passt die /etc/crypttab entsprechend an (sprich: man trägt in meinem Fall /dev/sda2 passend ein. Eventuell muss man die /etc/fstab auch noch anfassen, wenn man schonmal da ist.), ruft update-grub und update-initramfs auf, wechselt wieder raus, macht alle Mounts rückgängig und rebootet. Wenn man großes Glück hat, geht's danach. Wenn nicht, dann ist Fehlersuche angesagt.
Für diese Sucherei hab ich heute dann doch etwas gebraucht. Vor allem immer unter der Prämisse: bloß nüscht kaputtmachen, sonst musst du das doofe Backup zurückspielen. Mittlerweile läuft alles, nur eine Warnung beim Systemstart bzgl. des Einbindens von /home irritiert mich noch. Hat zwar keine Auswirkungen, aber das will ich auch noch rauskriegen. Später...
