staging.inyokaproject.org

Ich habe mir die BETA heruntergeladen und versucht Ubuntu in einer virtuellen Maschine auf ein verschlüsseltes RAID1 zu installieren. Ich habe schon einige Male gelesen, dass der Installer "kaputt" ist und irgendetwas in /etc/crypttab(?) nicht eingetragen wird. Ich kenne mich mit Linux leider nicht wirklich gut aus, also habe ich erstmal versucht das ganze mit dem alternate Installer alleine hinzukriegen. Folgendes habe ich getan:

Die zwei Festplatten sda und sdb habe ich in jeweils drei Partionen aufgeteilt sda1/sdb1 je 250mb sda2/sdb2 je 3gb sda3/sdb3 je 1gb

aus sda1/sdb1 habe ich ein raid1(md0) gemacht ("use physical volume for raid" und anschließend "md volume" o.ä. erstellen). Das gleiche habe ich für sda2/sdb2(md1) und sda3/sdb3(md2) gemacht. Soweit ich mich erinnere funktionierte alles prima, als ich die RAID-Partionen jetzt direkt als ext3 formatiere und md0=/boot, md1=/ und md2=swap setze.

Wenn ich aber für md1 und md2 jeweils "use as physical volume for encryption" auswähle und dann die verschlüsselten volumes für / und swap nutze, schlägt bereits die installation fehl. Zwei Fehler sind mir beim experimentieren mit diversen Kombinationen aus RAID,Encryption und teilweise auch noch LVM aufgefallen:

1. Statt GRUB wird versucht LILO zu installieren, was überhaupt nicht klappt. Es wird einem eine Auswahl von Installationsorten angeboten. Wenn ich dann manuell z.B. /dev/md0 angebe (die unverschlüsselte /boot-Partition) scheint es zu klappen, man erhält aber den Error Code 1 und erfährt, dass LILO nicht starten/laufen kann.

2. Alles scheint wunderbar, beim ersten booten landet man aber in einer busybox.

Weiß jemand, ob es Bestrebungen gibt den installer zu reparieren oder wird man auch auf lange Sicht die Installation auf einem verschlüsselten RAID mit einem der zahlreichen Tutorials lösen müssen, die es so gibt. Das Problem für mich ist nämlich v.a., dass ich keine Ahnung habe welche der tausend Möglichkeiten wirklich empfehlenswert sind und welche man lieber lassen sollte. Daher ist es mir nicht möglich ein geeignetes Tutorial zu wählen und so um den Fehler herumzugehen.

Du brauchst unbedinngt eine Partition außerhalb des Raid und des LVM, auf der /boot liegt.

• Mache also sda1 sdb1 jeweils 4G und noch ne sda2 mit 250M

• Dann raid auf sda1 und sdb1

• dann verschlüsseltes lvm auf dem raid (/dev/md0)

• und darin dann die restlichen partitionen

Ich werde das mal testen. Aber es ist meiner Meinung nach nicht so schön, dass /boot nicht durch das RAID1 geschützt ist. Außerdem hat die Konstellation mit 3xRAID1 (eine davon für /boot) auch funktioniert, sofern ich dann weder LVM noch Verschlüsselung benutzt habe. So, teste das jetzt aber erstmal...

EDIT: Klappt nicht!

Unter http://wiki.debian.org/DebianInstaller/RAIDvsCrypto gibt es Infos über die fehlenden Einträge in crypttab. Es funktioniert leider auch mit den dort angegebenen Tipps nicht. Ich habe es jetzt so gemacht:

sda: sda1 /boot-Partition sda5 RAID sda6 RAID sda7 RAID

sdb: sda1 do not use sda5 RAID sda6 RAID sda7 RAID

sda5+sdb5 als RAID 1. Die Partition da drauf verschlüsselt (=md0). für sda6+sdb6 und sda7+sdb7 das gleiche.

md0 (sda5+sdb5) dann als swap md1 als / md2 als /home

Wenn ich den Tipps unter dem angegebenen Link folge und folgendes in die crypttab eintrage: md0_cryptp1 /dev/md0 none luks md1_cryptp1 /dev/md1 none luks md2_cryptp1 /dev/md2 none luks

(habe das mit und ohne dieses 'p1' versucht) dann bootet das System zwar und will das Passwort für md0 haben, aber nach Eingabe des Passwortes wird "wrong fstype bla bla bla" angezeigt.

Wenn ich dem Link nicht folge, lande ich beim booten in einer busybox. Allerdings funktioniert cryptsetup luksOpen /dev/md1 md1_cryptp1 wunderbar mit dem Passwort.

Gleiches Problem (8.10 RC) wie TooLazyForName. Gibts mittlerweile eine Lösung? Denn wenn es im RC noch nicht gefixt ist dann wirds wohl auch kaum bis morgen in die Final kommen... (Testinstallation gleiches Szenario mit Fedora Core 9 funktioniert einwandfrei.)

EDIT: Fehler scheint an partman-md(41) zu liegen partman-md(42) ist gefixt (aber nicht in 8.10)...