Bootloader in Verbindung mit RAID1

[buhtz]

Habe das hier in einer VM ausprobiert und versuche den Hintergrund zu ergründen.
Etwas was ich unlogisch und unpraktisch finde, hat in der *nix-Welt sicherlich einen triftigen und wohlüberlegten Grund.

Ein RAID1 auf dem sich auch das System zum booten befindet.

Code: Alles auswählen

# lsblk -a
NAME    MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
sda       8:0    0   64G  0 disk  
└─sda1    8:1    0   64G  0 part  
  └─md0   9:0    0   64G  0 raid1 /
sdb       8:16   0   64G  0 disk  
└─sdb1    8:17   0   64G  0 part  
  └─md0   9:0    0   64G  0 raid1 /
sr0      11:0    1 1024M  0 rom   

Es scheint so, dass der bootloader nur auf der ersten Festplatte installiert wird.

Code: Alles auswählen

# dd if=/dev/sda bs=512 count=1 2>&1 | strings
ZRr=
`|f	
\|f1
GRUB 
Geom
Hard Disk
Read
 Error
1+0 Datens
tze ein
1+0 Datens
tze aus
512 bytes copied, 8,6398e-05 s, 5,9 MB/s

# dd if=/dev/sdb bs=512 count=1 2>&1 | strings
1+0 Datens
tze ein
1+0 Datens
tze aus
512 bytes copied, 6,7417e-05 s, 7,6 MB/s

Der Verdacht hat sich erhärtet, nachdem ich sda per mdadm auf fail gesetzt und dann entfernt habe. Das System bootet danach nicht mehr.

Es macht ein RAID1 mit /boot fast wertlos. Warum wird nicht per default der bootloader auf beide festplatten geschrieben, so dass das RAID1 dann auch beim Ausfall einer Platte nicht nur seine Daten behält, sondern eben auch weiterhin booten kann?

EDIT:
Nun hatte ich versucht den bootloader auf die zweite Platte zu kopieren. Per dd wahlweise die ganzen 512 (Bytes?) aber auch nur die 446. Dann die erste Platte enternt. In dem Fall sehe ich kein Bootmenu. Der bootloader der zweiten Platte wird scheinbar nicht angesprochen.

Dann hab ich, nach dem Entfernen der ersten Platte, die zweite einfach auf den ersten SATA Port gesteckt. Ebenfalls kein Bootmenu.

Was versteh ich hier falsch?

[smutbert]

Sicher bin ich mir nicht, aber ich vermute, deine Chancen auf Erfolg sind größer wenn du tatsächlich grub auf beide Platten installierst. grub liegt ja in mehreren Teilen vor, stage1, stage1.5 und/oder stage2 (letzteres beinhaltet die ganzen grub-Module und die Konfigurationsdatei mit dem Menü, die alle von /(boot) nachgeladen werden) und wenn irgendeine ID oder so etwas nicht übereinstimmt, funktioniert schnell gar nichts mehr.
(Mit uefi wäre wieder einiges anders und meiner Meinung nach durchschaubarer, aber nicht einfacher.)

Am bequemsten kannst du mit

Code: Alles auswählen

dpkg-reconfigure -p low grub-pc

grub auf mehrere Platten installieren lassen – das passiert dann auch bei Updates uä.

[buhtz]

Sicher bin ich mir nicht, aber ich vermute, deine Chancen auf Erfolg sind größer wenn du tatsächlich grub auf beide Platten installierst.
...
Am bequemsten kannst du mit

Code: Alles auswählen

dpkg-reconfigure -p low grub-pc

So geht es in der VirtualMachine. Das booten ohne die erste Platte dauert nur ein paar deutliche Sekunden länger. Liegt wohl daran, dass ich diesmal kein --fail und --remove gemacht habe, sondern die Platte einfach rausgezogen habe.

Habe das nun auch auf meinem Produkttiv-System versucht und bekomme die Meldung, dass sich grub nicht auf die zweite Platte installieren lässt. Im "Konfiguriere grub-pc" Dialog sieht die Meldung so aus:

Code: Alles auswählen

│ GRUB konnte nicht auf den folgenden Geräten installiert werden:                                     │ 
│ /dev/sdc                                                                                            │ 
│ Wollen Sie trotzdem fortfahren? Falls ja, wird Ihr Rechner vielleicht nicht problemlos hochfahren.  │ 
│ GRUB konnte nicht auf das Boot-Gerät geschrieben werden - fortfahren?  

Der bash-output sieht so aus

Code: Alles auswählen

$ sudo dpkg-reconfigure -p low grub-pc
[sudo] Passwort für admin: 
i386-pc wird für Ihre Plattform installiert.
installation beendet. Keine Fehler aufgetreten.
i386-pc wird für Ihre Plattform installiert.
grub-install: Warnung: Diese GPT-Partitionsbezeichnung hat keine BIOS-Boot-Partition, Einbettung würde unmöglich sein.
grub-install: Fehler: Einbettung ist nicht möglich, jedoch für die Installation mit RAID und LVM erforderlich.

Nicht wundern, die zweite Platte ist tatsächlich sdc. sdb ist ein on-board Speicher-Chip.

Code: Alles auswählen

[*] /dev/sda (4000787 MB; ST4000VN000-1H4168)     │ 
[ ] /dev/sdb (515 MB; USB_DISK_MODULE)            │ 
[*] /dev/sdc (4000787 MB; WDC_WD40EFRX-68WT0N0)   │ 
[ ] /dev/md0 (4000464 MB; SPARKY:0)    

Die Geräte-Partitions-Struktur sieht bei dem Produktivsystem so aus.

Code: Alles auswählen

$ sudo lsblk -a
NAME    MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
sda       8:0    0  3,7T  0 disk  
├─sda1    8:1    0  3,7T  0 part  
│ └─md0   9:0    0  3,7T  0 raid1 /
└─sda2    8:2    0   10M  0 part  
sdb       8:16   1  492M  0 disk  
└─sdb1    8:17   1  490M  0 part  [SWAP]
sdc       8:32   0  3,7T  0 disk  
└─sdc1    8:33   0  3,7T  0 part  
  └─md0   9:0    0  3,7T  0 raid1 /

LÖSUNG (ohne es wirklich zu verstehen):
Habe noch eine zusätzliche 10MB große Partition vom Typ "Bios boot" erstellt. Warum man das tun muss, weiß ich nicht. Aber es geht.

Code: Alles auswählen

Device          Start        End    Sectors  Size Type
/dev/sdc1        2048 7813670911 7813668864  3,7T Linux filesystem
/dev/sdc2  7813670912 7813691391      20480   10M BIOS boot

[smutbert]

Das ist notwendig, weil bei gpt ein Speicherbereich, der bei msdos/mbr-Partitionierung frei ist und von grub für stage1.5 (glaube ich) genutzt wird, für die Partitionstrabelle gebraucht wird. Ersatzweise stellt man den Platz eben in Form einer eigenen Partition zur Verfügung. Für die ist übrigens 1 MB leicht genug (ich mach solche Partitionen aber auch immer größer als notwendig).