dridde bloggt. manchmal.

Die Folgende Episode “Grub2-Truecrypt-Multiboot Hass” wird ihnen präsentiert von Debian Testing.

Wenn heute der einzige Abend gewesen wäre, an dem ich mich mit Grub2 herumgeschlagen habe, dann würde ich vermutlich nichts darüber schreiben. Aber das ist der xte Abend, der dafür draufgeht, mein vermutlich zu exotisches Setup wieder hinzufrickeln.

Ich nutze Aktiv zwei Rechner, ein Subnotebook das ich meistens mit mir herumschleppe und auf dem nur ein Debian unstable drauf ist. An dem sitze ich die ganze Zeit und betrachte das Ding als meinen Hauptrechner. Nicht viel Wumms, aber immer dabei. Keine abgefahrene Hardware, ein alter Core2Duo und Intel Onboardgrafik. Der macht so gut wie nie Probleme, außer ich installiere planlos die unstable Updates, dann bin ich aber selbst Schuld.
Das System ist ein single Boot Debian mit verschlüsselter Festplatte, mehrere volumes in einem lvm in einem dm-crypt. Ziemlich Standard. Bootloader ist Grub2 im mbr von /dev/sda – keine Probleme, alles tut wie es soll.

Die andere Kiste ist ein Thinkpad T410 mit Core i5 und Nvidia-Karte ohne Optimus, dass ich mal günstig irgendwo gekauft habe. Da das etwas mehr Wumms und Grafikschmackes hat, ist das auch der Rechner auf dem ich gelegentlich mal Zocke. Daher ist das Setup auf dem Rechner etwas komplizierter: Ein mit Truecrypt verschlüsseltes Windows 7 zum zocken und ein Debian testing um damit zu arbeiten.

Die Festplatte ist folgendermaßen aufgeteilt. sda1 enthält den Windows 7 Boot-kram, sda2 das Windowssystem, sda3 ist die Bootpartition des Linuxsystems, sda4 ein verschlüsselstes lvm-Volume mit /root /home und swap. Der Truecrypt Bootloader muss im MBR der Festplatte sein, Grub nicht zwingend. Daher war das (bei Debian inzwischen standardmäßig verwendete) Grub2 in /dev/sda3 installiert. Das klappt normalerweise recht gut, geht aber auch regelmäßig schief. Eine Zeit lang installierte sich Grub2, wenn es eine neue Version gab, ungefragt nach /dev/sda, übeschrieb also den TrueCrypt Bootloader im MBR und verhinderte das Booten von Windows. Das ließ sich durch die Rescue-CD von Truecrypt recht leicht reparieren, das Windows bootete dann wieder, das Debian auch, da ja noch ein Grub in /dev/sda3 installiert war. Aus Debian heraus konnte dann einfach via grub-install /dev/sda3 die neue Grub2-Version in die Partition installiert werden und alles war gut. Nervig aber irgendwann hatte ich eine gewisse Routine und wusste was passieren würde, wenn da eine neue Grub2 Version in den Repositories auftauchte.

Dann irgendwann meckerte Grub2, wenn man es in Partitionen installieren wollte. Das und das Verwenden von Block Devices wäre eine dumme Idee, es ließ sich aber durch ein beherztes –force doch noch davon überzeugen, dass man das wirklich wollte. Manchmal zerschossen die apt-install-Scripte dabei dann auch noch den TrueCrypt Bootloader, so dass erstmal gar kein System booten konnte. Das hatte sich nach dem “retten” des Truecrypt Loaders aber immer wieder.

Der neuste Spaß ist aber, dass sich die Grub2 Versionen 1.99-17 und 1.99-18 aus dem Debian testing und unstable nicht mehr in eine Partition installieren lassen. Die Scripte tun jetzt was sie sollen und installieren grub2 dorthin, wo es liegt, in meinem Falle nach /dev/sda3. Soweit so schön, aber das Grub2 im /dev/sda3 hat das Update nicht überlebt, bzw wurde “so halb” installiert. Nach mühsamen händischen zusammenbasteln meiner Umgebung und rein-chrooten stellte ich dann fest, dass grub-install ein Problem mit /grub/core.img hat und die Datei “nicht korrekt lesen kann”. Das ist ne dreiste Lüge, lesen kann er die nämlich schon, er kann sie wohl nur nicht in die Partition schreiben.

Einen spanndenden Googleabend später weiß ich, dass das wohl ein Bug ist, der laut debian-Bugtracker schon einmal in 1.99-15 gefixt wurde. Spannend daher, da ich gerade kein DSL habe, via Telefon tethere und mein Datenvolumen schon aufgebraucht habe. Also geht’s mit 64kbit ins Internet. Die 90er haben angerufen. Glücklicherweise sehen die meisten HowTos und Bugtracker auch noch aus wie Webseiten aus den 90ern und laden daher halbwegs schnell. Jedenfalls ist der Bug wohl in 17 bzw. 18 wieder drin. Das Problem scheint auch nicht neu zu sein, einige Blogeinträge ließen auch vermuten, dass entweder die img-Datei zu groß oder der Platz für Grub zu klein wäre. Jedenfalls ist das ein Problem, dass nur auftritt, wenn man versucht in eine Partition zu installieren. Ich habe mit 1.99-17 und 1.99-18 getestet, in die Partition ney, in den MBR hey!

Was leider mit Grub2 nicht geht ist ein Chainloading des Truecrypt Bootloaders durch Grub2, so dass ich Grub2 in den MBR installieren und trotzdem das Windows nutzen kann. Spaßigerweise geht das aber mit Grub1, also Grub-Legacy. Das war dann am Ende nach gut 3 Stunden Bespaßung und Googlen meine Lösung. Den Truecrypt loader via

dd if=/dev/sda of=/boot/truecrypt.mbr count=1 bs=512

aus dem MBR gepuhlt, grub2 deinstalliert, Pakete für Grub-Legacy hernutergeladen, den in den MBR installiert und für Windows einen Eintrag in der /boot/grub/menu.lst

title Windows 7
rootnoverify (hd0,0)
makeactive
chainloader (hd0,2)/truecrypt.mbr
boot

angelegt. Da Grub-legacy nicht mehr aktiv weiterentwickelt wird sollte das wohl eines der Provisorien sein die sehr lange halten. Irgendwelche Updates dafür erwarte ich zumindest in nächster Zeit nicht und ich kann mein Debian und auch das Windows booten. Trotzdem ärgerlich, damit wieder einen Abend auf den Kopf gehauen zu haben.

Ich frage mich aber zum wiederholten mal, ist mein Setup wirklich so ungewöhnlich, ein Windows und ein Linux auf einem Laptop parallel zu betreiben und dabei beide Systeme verschlüsseln zu wollen? Für mich sind so Bootloaderprobleme einfach mal echte “show-stopper”. Jeder Linuxanfänger ist mit solchen Problemen sicher überfordert und danach ausreichend abgeschreckt “das mit Linux” sein zu lassen.