[Eisfair] [e1] eiskernel 2.8.0 (Status 'stable') verfügbar - 3.2er Kernel für eisfair-1

[Stefan Welte]

Hallo Thomas,

Am 27.02.2015 um 00:53 schrieb Thomas Bork:
> Das hat bei ihm mit HOMEHOST zu tun. Das Raid wurde auf einem anderen Host erstellt und deswegen ist mdadm
> etwas zickig:
je nach Betrachtungsweise...

"mdadm -Es" liefert auf meinem eisfair mit 2.6er Kernel:
> ARRAY /dev/md/data-raid1  metadata=1.2 UUID=2828347a:cf1db600:e7afe499:791fb662 name=eis1:data-raid1

Exakt dies wurde bei der Installation vom 3.2er Kernel direkt in die mdadm.conf der initrd geschrieben,
obwohl es in der initrd weder ein /dev/md-Verzeichnis noch ein passendes /dev/md/data-raid1-Blockgerät gibt.
Mit udev ist das problemlos, weil automatisch erzeugt, aber soweit ich weiss, ist eisfair udevlos. Daher
konnte der initiale Boot mit dem 3.2er Kernel nicht klappen.

Meine Korrektur der initrd (-> /dev/md1) fruchtete nicht, weil ich Schussel lilo nicht ausführte. Ich bin
etwas grub-verwöhnt (und das wurde zu meinem Verhängnis mit einer länglichen Odysse), startete
hektischerweise die Maschine statt über grub mit lilo, das vermutlich auf die alte, "ge-mv-te) initrd
Zugriff und es sich keine Besserung beim Bootvorgang ergab.
Leider habe ich mich gegen Marcus's Vorschlag das /dev/md127 zu erstellen entschieden, da es bei Wechsel
zwischen 2.6er und 3.2er Kernel immer die Änderung in der /etc/fstab gefordert hätte; bis heute nicht
getestet, hätte aber evtl. funktioniert.
Weiter gings mit Änderung des name und hostname in den Metadaten unter grml-livelinux-System, aber auch
wegen fehlender lilo-Ausführung (mache ich ungern über chroot), aber lilo-Bootloaderbenutzung statt grub-,
keinerlei Erfolge. Die Zeit wurde später und die Konzentration weniger, letztlich bootete nichtmal mehr der
2.6er Kernel, da hostname und name des Raid geändert wurden, habe ich statt diese zurückzusetzen, die initrd
geändert, bis es zum kernel-Panic gleich zu Beginn des Bootvorgangs kam. Zuerst dachte ich beim gzip was
schiefgelaufen, aber nach ein Mal drüber schlafen, ist mir gestern Abend das mit lilo in den Sinn gekommen...
Mit grub (später, wenn ich lilo eingerichtet habe damit) lässt sich wieder 2.6er und sogar der 3.2er Kernel
booten. Allerdings stehen in der initrd noch diverse (zumindest /dev/md/ /dev/md127) Zusätze drin und weiß
noch nicht, wenn ich diese wieder entferne, ob das Raid dann noch als /dev/md1 startet, was es derzeit unter
3.2 tut, erstaunlicherweise mit der kompletten mdadm.conf-Zeile:
> ARRAY /dev/md1  metadata=1.2 UUID=2828347a:cf1db600:e7afe499:791fb662 name=eis1:data-raid1

Könnte man das 2.8.0-eiskernel-Paket derart abändern, daß ein laufendes Raid korrekt/korrigiert und nicht
mit der Ausgabe von "mdadm -Es" in die mdadm.conf der initrd aufgenommen wird (falls das derzeit so passiert
:-) )?
Zuvor kann ich ggf. den 2.8.0er-Kernel nochmal installieren und nur /dev/md/data-raid1 zu /dev/md1 ändern,
damit man sieht, ob dies die einzige Ursache ist.

> Wer so etwas macht (Raids auf anderen Systemen erstellen und dann in eisfair einzuhängen), muss mit den
> Folgen leben oder sie selbst gerade biegen können.
jup. :-)
Allerdings ist ein Erstellen eines zwoten RAID1 bei laufendem eisfair mit bestehendem, nichtdegradatiertem
RAID1 bei zwei SATA-Anschlüssen aber vier SATA-Platten nicht möglich. Da ich eisfair nicht mit
degradatiertem RAID1 starten wollte, hatte ich mich für ein Livelinuxsystem entscheiden, von wo aus ich auf
das alte RAID1 mit metadata 0.9 mit direktem Dateisystemmount lesend auf die alten Daten Zugriff, um sie auf
das neue RAID1 (dieses mit missing Device) zu kopieren. Damals schien mir diese Methode (und war sie auch)
sehr sicher gegen "Unfälle" beim Umzug, jedoch mit den folglichen Inkompatibilitäten zu eisfair, allen voran
udev.

Kennt jemand eine Livelinuxdistribution ohne udev bzw. die sich wie eisfair verhalten?
Grml schien das 2008 per Cheatcode "noudev" implementiert zu haben, aber aktuell finde ich den Parameter
nicht mehr in der Liste [1][2].
Kann es sein, daß Raid1-Partitionen mit metadata 1.2 sich nicht mehr direkt mounten lassen?

Danke und Gruß,
Stefan

[1] https://www.google.de/?gws_rd=ssl#q=grml+noudev
[2] http://git.grml.org/?p=grml-live.git;a=blob_plain;f=templates/GRML/grml-cheatcodes.txt;hb=HEAD