Nachträgliche Installation eines RAID1 Verbundes auf ein bestehendes System

[ralfi]

Hallo siducer allesamt,

das ist hier eine Fortführung meines letzten Posts, aber der Übersichtlichkeit halber mach ich das nochmal extra auf. Es geht darum, eine existierende siduction Festplatten-Installation mit Hilfe einer weiteren Festplatte auf ein RAID 1 System zu erweitern. Das hab ich mit GRUB 1.9x schon einmal erfolgreich gefrickelt, aber mit der aktuellen cinnamon-nox und einer virtuellen Qemu Maschine klappt das nicht.

Es gibt diverse Anleitungen im Netz. Die meisten sind auch bis zu der Stelle brauchbar, wo das erste Mal vom erstellten und noch nicht synchronisierten RAID (also der manuell konfigurierten zusätzlichen Festplatte des RAID Verbundes mit den kopierten Daten der ersten Platte) gestartet werden soll. Das meine Konfiguration nicht so völlig falsch sein kann, zeigen folgende Informationen, gebootet von Live-CD bzw. auch von der noch funktionierenden GRUB Installation der ersten Platte:

Code Select Expand


blkid:
/dev/sr0:   UUID="2014-...."
/dev/vda1:  UUID="f0b3..." TYPE="ext4" PARTUUID="deec.."
/dev/vdb1:  UUID="c78c..." UUID_SUB="dfd6f..." LABEL="cinna-nox:0" TYPE="linux-raid_member" PARTUUID="a6d1..."
/dev/md0:   UUID="9ca2..." TYPE="ext4


Code Select Expand


/proc/mdstat

Personalities: [raid1]
md0: active raid1 vdb1[1]
     2095104 blocks super 1.2 [2/1] [_U]

unused devices: <none>


Um von der noch nicht synchronisierten RAID Platte zu booten, habe ich mir eine zusätzliche GRUB Start Option in der Konfiguration der ersten Festplatte erstellt:

Code Select Expand


/etc/grub.d/40_raid_start

#! /bin/sh -e
echo "Systemstart RAID" >&2
cat << EOF
menuentry 'Systemstart RAID Konfiguration' --class siduction --class gnu-linux {
  insmod mdraid1x
  insmod ext2
  set root='hd1,msdos1'
  search --nofloppy --fs-uuid --set=root 9ca2...
  echo 'Linux wird geladen...'
  linux /boot/vmlinuz-3.17-4.towo-siduction-amd64 ro root=UUID=9ca2...
  echo 'Initiale Ramdisk wird geladen...'
  initrd /boot/initrd.img-3.17-4.towo-siduction-amd64
}
EOF


Das geht auch insoweit vorzüglich, als das der Kernel bei Auswahl dieser GRUB-Option gefunden und geladen wird, u.a. auch nachvollziehbar an der Kernelmeldung

Code Select Expand


Success: assembled all arrays.



Allerdings kackt dann das Laden der Inird ab da das RAID Filesystem nicht gefunden werden kann, das sieht wie folgt aus:

Code Select Expand


Gave up waiting for root device. Common problems ...
ALERT! /dev/disk/by-uuid/9ca2... does not exist
(initramfs)


Habe ich mir natürlich gedacht, vielleicht ist mdadm nicht in der Initrd, aber dies ist wohl doch so denn ...

Code Select Expand


(initramfs) cat /proc/modules |grep raid

raid1 23400 1 - Live 0xff...
md_mod 87451 1 raid1, Live 0xff...


Das RAID ist in der Initrd auch als /dev/md0 verfügbar

Wenn ich von der Live-CD starte, kann ich auch keine der im Handbuch beschriebenen Methoden zur nachträglichen Installation von GRUB anwenden denn dann wird auch immer mit Verweis auf den fehlerbehafteten Blockdevices-Modus bzw. nicht vorhandene Geräte (Null) die Installation verweigert wobei ich eigentlich bisher immer problemlos mit der chroot Methode solche Probleme lösen konnte.

Habe ich da irgendetwas übersehen? Muss ich vielleicht doch eine angepasste Initrd erstellen und wenn ja wie geht das denn? Bin wie immer für alle Tipps dankbar!

[melmarker]

und irgendwie hab ich jetzt das Problem nicht verstanden oder ein Schlüsselwort nicht in dem langen Text gelesen

Ralfi: Das magische Wort heisst "degraded" - jedes System, was auf sich hält, wird sich erst mal weigern, mit einem  degraded raid zu booten, dat muss man mdadm (statisch) oder dem Kernel (dynamisch oder statisch) schon erzählen

https://wiki.ubuntu.com/BootDegradedRaid

Hint - dass man - nur für den Fall, dass man mit Masterbootrecords arbeitet - die auch auf jedes beteiligte Eisen bannt, versteht sich dann eigentlich auch von selbst, wird aber sehr gern vergessen)

[ralfi]

Huhu melmaker,
vielen Dank für den heissen Tipp.

Nach Erstellung von /etc/initramfs-tools/conf.d/mdadm mit Inhalt "BOOT_DEGRADED=true", dem Update der Initrd mit "update-initramfs -u" und dem Kopieren der neu erstellten Initrd-Datei auf die RAID Platte vdb1 funktioniert jetzt das Starten über GRUB über vda1 in das DEGRADED RAID auf vdb1 ganz genau so wie es soll.

[melmarker]

ralfi: degraded und das mit grub kommt besonders gut bei entfernten Systemen, die ohne dieses Wissen aufgesetz wurdn und wo dann wirklich mal eine Platte den Geist aufgibt - also alles schon live gesehen und reingelaufen

[ralfi]

Es erschien mir alles etwas müsteriöös, deshalb hab ich dieses System nochmal komplett neu aufgesetzt. Insbesondere ging es mir um die Frage, wie sich das Testsystem bei Ausfall einer Platte verhält und dann sicher mit dem degraided RAID neu startet.

Ich weiss natürlich nicht inwieweit mit den Kernel-Aktualisierungen Änderungen vom towo in der Initram mit eingebaut sind, aber auf jeden Fall bootet das System mit aktuellsten 3.18-3 auch auch ein Degraided RAID völlig ohne Modifikationen und es sind auch alle notwendigen Module bereits in der RAM-Disk. Was ich noch nicht begriffen habe ist, inwieweit ein "update-initramfs" die jeweils aktuellen, z.B. per Hand nachgeladenen Kernel-Module mit in das neue Image einklebt.

Und noch etwas ist mir aufgefallen. Damit bei einem Ausfall einer RAID-Platte das System noch hochfährt installiert man ja grub-pc in den MBR aller Festplatten. Ein "update-grub" schreibt dann die GRUB-Konfigurationen neu. Der Kernel soll dann bspw. wie folgt geladen werden:

Code Select Expand


linux     /boot/<towo-Kernel> root=UUID=<UUID des RAIDs> ro quiet


Mit "blkid" habe ich kontrolliert, dass die UUID richtig ist. Trotzdem startet der Kernel nicht, offensichtlich wird die UUID nicht korrekt in das eigentliche RAID Device /dev/md0 aufgelöst. Wenn ich das ändere, und zwar so

Code Select Expand


linux     /boot/<towo-Kernel> root=/dev/md0 ro quiet


funktioniert alles fehlerfrei. Woran kann das denn liegen?

[ralfi]

Sorry, das war falsch. Der Kernel wird richtig geladen, allerdings findet die Initiale Ramdisk nicht das korrekte RAID Device /dev/md0. Die Fehlermeldung lautet:

Code Select Expand


ALERT: /dev/disk/by-uuid/<UUID des RAID> does not exist.



Wie gesagt, mit der Kernel Startoption /dev/md0 an Stelle der UUID funktioniert alles fehlerfrei.