Debian mit RAID1 LUKS LVM bootet nicht

[DEFCON2]

Habe Debian mit dem graphischen Netzwerkinstaller installiert, es bootet jedoch nicht.

Vorhanden sind 2x500 GB HDDs, auf denen ich entsprechend dem Arch-Wiki folgendes Setup angestrebt habe:

+-----------------------------------------------------------------------+ +----------------+
| Logical volume 1      | Logical volume 2      | Logical volume 3      | | Boot partition |
|                       |                       |                       | |                |
| [SWAP]                | /                     | /home                 | | /boot          |
|                       |                       |                       | |                |
| /dev/MyVolGroup/swap  | /dev/MyVolGroup/root  | /dev/MyVolGroup/home  | |                |
|_ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _| | (may be on     |
|                                                                       | | other device)  |
|                         LUKS encrypted partition                      | |                |
|                           /dev/sda1                                   | | /dev/sdb1      |
+-----------------------------------------------------------------------+ +----------------+

Darunter liegt noch ein Software RAID1 (der Hardware RAID Controller der Workstation wird nicht unterstützt - keine Festplatten im Installer sichtbar, wenn Hardware RAID aktiviert ist), so dass die obige Anordnung gespiegelt auf beiden Platten vorliegen sollte.

Der bootloader soll also in eine nicht verschlüsselte, eigene Partition (/boot). Im Debian Installer hab ich eine der beiden Festplatten vom RAID als Zielort für die Installation von GRUB ausgewählt (ansonsten war dort nur der USB-Stick von dem ich installiere aufgelistet) und nicht in den Master Boot Record installiert.

Nach Neustart wird der Bootloader nun offenbar nicht gefunden oder aufgerufen: "Reboot and select proper boot device"

Wie kann ich die Installation retten?

 

[Evil E-Lex]

Nach Neustart wird der Bootloader nun offenbar nicht gefunden oder aufgerufen: "Reboot and select proper boot device"

Nach meinem Verständnis ist das logisch. Woher soll das BIOS wissen von wo es booten soll, wenn auf der ersten Festplatte in der Reihenfolge kein MBR vorhanden ist?

 

[snaxilian]

Einfach GRUB auf beide Disks installieren, dann bootet das System auch bei Ausfall einer Disk
Die Skizze verwirrt btw mehr, dass Sie hilft, da du ja eben nicht zwei einzelne Disks verwendest sondern beide zusammen ein gespiegeltes Blockdevice ergeben. Darauf dann LUKS und /boot und im LUKS-"Container" bzw. Blockdevice dann ein LVM mit Swap, / und /home.
Btw du solltest im besten Fall noch mindestens /var/log in ein eigenes LV stecken, Bonuspunkte für /tmp, /usr & /var. Kann vor unschönen und/oder Amok-laufenden Prozessen schützen.

 

[DEFCON2]

Ich ging davon aus, das es dann mit einer Guid Partition Table statt MBR abläuft, wenn ich beim Debian installer letzteres abwähle- ansonsten wäre es ja völlig sinnlos. Die Workstation ist von 2012 und EFI fähig.

GRUB im LUKS Container ging auch nicht, daher hab ich im zweiten Anlauf extra diese unverschlüsselte Partition angelegt.

Die Skizze finde ich an sich schon logisch. Da sind doch gar keine einzelnen Disks zu sehen? Anstatt auf einer Festplatte mache ich das ganze eben auf einem RAID1, das sollte aber nichts ändern, hoffe ich.

 

[Evil E-Lex]

Die Skizze geht von zwei physischen Laufwerken aus: /dev/sda und /dev/sdb. Hast du diese auch?

 

[DEFCON2]

Nein, das sind zwei verschiedene Partitionen, aber auf der selben physikalischen Platte

 

[snaxilian]

Sorry aber definitiv nein: Die Platten werden definiert durch den letzten Buchstaben (sda & sdb), die Partitionen auf den Platten dann durch fortlaufende Zahlen dahinter. Daher sind dies im Bild oben zwei verschiedene Platten und nicht für deine Situation passend wenn du ein Raid 1 verwendest.
Ersetze einfach MBR durch GPT in meinem ersten Post, der Lösungsweg bleibt identisch, denn sowohl GPT als auch MBR beschreiben den Anfang einer Disk wo die Partitionsinformationen stehen. So oder so wird "darein" der GRUB installiert wobei da nix anderes passiert als das Boot-Flag für die Platten zu setzen und eine Info hinterlassen in welcher Partition sich dann der Bootmanager, in dem Fall GRUB, befindet.

Mit LVM ist es dann ja auch nicht mehr notwendig, zig verschiedene Partitionen anzulegen sondern man arbeitet ebenmit flexibleren LVs.

 

[DEFCON2]

Ich verstehe was du meinst, aber ich denke es ist dennoch sinnvoller so wie ich es beschrieben habe - wer hat denn bitte eine eigene Festplatte nur für den bootloader im PC? Und wenn ich nur eine Platte hätte, dann würde ja auch nur eine eigene Partition und keine eigene Platte für diesen zur Verfügung stehen.

Ob der bootloader jetzt ein eigenes Volume auf dem RAID oder innerhalb des LUKS Volumen bekommt ist mir erstmal egal. Ich ging davon aus, dass außerhalb/unverschlüsselt weniger Probleme machen würde.

Ergänzung (12. Juli 2018)

Ich hab nochmal ganz genau deinen Beitrag gelesen und festgestellt, dass ich es genau so, wie du es oben empfohlen hast auch gemacht habe.

 

[Evil E-Lex]

Sorry aber definitiv nein: Die Platten werden definiert durch den letzten Buchstaben (sda & sdb), die Partitionen auf den Platten dann durch fortlaufende Zahlen dahinter. Daher sind dies im Bild oben zwei verschiedene Platten und nicht für deine Situation passend wenn du ein Raid 1 verwendest.

Exakt. In der Grafik müsste bei einer Platte /dev/sda2 statt /dev/sdb1 stehen. (Für ein md-Blockdevice dann entsprechend /dev/md0 und /dev/md1).

Zwei Ideen:
- Die UEFI-Firmware findet den Bootloader nicht, weil der nicht auf der ersten Partition liegt.
- Der Bootloader muss in der UEFI-Firmware explizit angegben werden.
Das sind aber nur Spekutationen meinerseits, mit Linux-UEFI-Boot kenn ich mich nicht aus.

 

[DEFCON2]

Also die Reihenfolge der /boot Partition und des LUKS Containers hab ich jetzt mal umgedreht, ohne dass es was gebracht hätte. Im UEFI kann ich nur das Boot Device auswählen, mehr Einstellungen gibt es da nicht. Eventuell gibts in der Intel Management Engine welche, da hab ich aber keinen Passwortzugriff drauf.

Hab es auch mit Ubuntu 18.04 LTS probiert, wobei schonmal der Hardware-RAID Controller erkannt wurde. Nach Installation aber auch hier kein Boot.

Habe das System jetzt ohne das RAID1 auf nur einer Platte installiert, das hat geklappt, ist aber natürlich nicht, was ich mir gewünscht hatte.

 

[snaxilian]

Bei UEFI muss nicht nur /boot beim Start lesbar sein sondern afaik auch die EFI Partition. In der Regel ist dies /boot/efi und diese muss mit FAT32 formatiert sein.

Da du deine Installation nicht wirklich hier dokumentiert hast hier der manuelle Weg zu Fuß:
Debian Installer starten aber die erweiterte Version. Platten manuell partitionieren und zuerst ein Raid 1 anlegen.
Erstelle eine GPT Partitionstabelle auf /dev/md0 (bzw dem dir angezeigten Raid-Device.
Erstelle eine Partition mit ext4 und verwende diese als /boot auf /dev/md0.
Erstelle eine Partition mit fat32 und verwende diese als /boot/efi auf /dev/md0.
Erstelle einen LUKS-Container auf /dev/md0 im restlichen freien Speicherbereich.
Erstelle in dem LUKS-Container eine PG bzw weise dies so zu. Vernwende diese PG als Volume Group (VG). Erstelle deine Logical Volumes (LVs) in der VG für deine gewünschten Partitionen, z.B. /, /home, /var/log, /tmp, etc mit gewünschtem Label, Dateisystem, Größe, usw.