[erl] Software-RAID + EFI

[Lamont]

Hallo Zusammen,

nach über 10 Jahren Treue soll mein Homeserver ein neues Innenleben bekommen. Meine Konstellation, die sich bis jetzt bewährt hatte, schaut im groben wie folgt aus: 2 Platten im Software RAID1. Dabei ist mir wichtig, dass das System auch beim Ausfall einer Platte bootet.

Jetzt bin ich bei der Vorplanung auf die Problematik Software-RAID + EFI gestoßen. So wie ich es verstanden habe, gibt es hierfür noch keine wirklich saubere Lösung, sondern man muss sich mit dem manuellen Kopieren der EFI-Partition behelfen:
https://www.thomas-krenn.com/de/wiki/Ub ... _Einträgen

oder recht tief in die Frickelkiste greifen:
https://outflux.net/blog/archives/2018/ ... and-raid1/

Jetzt zu meiner Frage: Könnte ich alternativ auch eine Installation via BIOS (CSM, Legacy Mode) und GPT vornehmen oder würde ich hier auf die dieselbe bzw. eine ähnliche Problematik (wegen der BIOS-Bootpartition) stoßen?

Meine Platten sind zwar kleiner als 2 TB, aber auf die Variante MBR + BIOS möchte ich eigentlich nicht ausweichen.

[willy4711]

Jetzt zu meiner Frage: Könnte ich alternativ auch eine Installation via BIOS (CSM, Legacy Mode) und GPT vornehmen oder würde ich hier auf die dieselbe bzw. eine ähnliche Problematik (wegen der BIOS-Bootpartition) stoßen?

Nach meinem Wissen ist es für deinen Zweck (RAID 1) egal, ob du mit GPT oder MBR partitionierst
Abgesehen natürlich von den Vorteilen einer GPT- Partitionierung.
Es wird halt nur zusätzlich der sekundäre Backup-GPT am Ende der Platte mit gespiegelt.

Das UEFI ist dann "außen vor" und verhält sich wie ein normales BIOS.

Der Unterschied GPT / MBR ist sehr schön hier beschrieben:
https://www.heise.de/tipps-tricks/Festp ... 51715.html
Ganz genau:
https://de.wikipedia.org/wiki/GUID_Partition_Table

[Lamont]

Hallo Willy,

vielen Dank für die Rückmeldung.

Die Lösung mit MBR möchte ich ja nach Möglichkeit vermeiden. Mir ging es bei meiner Fragestellung primär darum, ob es evtl. eine andere brauchbare Alternative gibt, bei der ich bei einer GPT-Partitionierung + Software-RAID bleiben kann.

Da EFI System Partitionen anscheinend nicht gespiegelt werden können, besteht zumindest theoretisch das Risiko, dass diese Partitionen irgendwann auseinanderlaufen und dann ein booten über die zweite Platte nicht mehr möglich ist. Zumindest habe ich es so verstanden

[willy4711]

Da EFI System Partitionen anscheinend nicht gespiegelt werden können, besteht zumindest theoretisch das Risiko, dass diese Partitionen irgendwann auseinanderlaufen und dann ein booten über die zweite Platte nicht mehr möglich ist. Zumindest habe ich es so verstanden

Wenn du nicht im UEFI- Modus installierst, brauchst du auch keine EFI-Partition.
Die wird auch dann nicht angelegt.

Edit:
So sieht das dann aus:


Meine Bootpartition [/dev/nvme1n1p1 ]auf /dev/nvme1n1:

Code: Alles auswählen

Partition number (1-3): 1
Partition GUID code: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem)
Partition unique GUID: FBC4CC7D-59B4-4BC8-AB68-DA50A0C26810
First sector: 2048 (at 1024.0 KiB)
Last sector: 97656831 (at 46.6 GiB)
Partition size: 97654784 sectors (46.6 GiB)
Attribute flags: 0000000000000000
Partition name: ''

Nur vorn und hinten jeweils 2048 KiB

Komplett:

Code: Alles auswählen

fdisk -l /dev/nvme1n1
Festplatte /dev/nvme1n1: 953,89 GiB, 1024209543168 Bytes, 2000409264 Sektoren
Festplattenmodell: Viper M.2 VPN100                        
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes
E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes
Festplattenbezeichnungstyp: gpt
Festplattenbezeichner: B6F38518-983A-428C-8473-D45336DE9236

Gerät              Anfang       Ende   Sektoren  Größe Typ
/dev/nvme1n1p1       2048   97656831   97654784  46,6G Linux-Dateisystem
/dev/nvme1n1p2   97656832 1953126399 1855469568 884,8G Linux-Dateisystem
/dev/nvme1n1p3 1953126400 2000408575   47282176  22,6G Linux Swap

[Lamont]

Falls es jemanden interessieren sollte

Ich habe mich jetzt an dieser Anleitung orientiert (ohne LVM):
https://askubuntu.com/questions/1066028 ... 41#1066041

Ein "manuelles Monitoring" ist bei dieser Lösung allerdings nötig:
"When the package grub-efi-amd64 is updated, the files on the EFI partition (mounted at /boot/efi) may change. In that case, the update must be cloned manually to the mirror partition. Luckily, you should get a warning from the update manager that grub-efi-amd64 is about to be updated, so you don't have to check after every update."