Re: Aufruf von mdadm in der initrd
* Gerhard Brauer:
> Ah, jetzt ja. Nachdem ich mir mal man mkinitrd angeschaut habe,
> verstehe ich dein Problem. Also Skripte, um das Raid zu
> initialisieren müßten wirklich in die initrd. Wobei ich allerdings
> irgendwie bezweifle, daß mdadm da wirklich benötigt wird.
Nein! Ich könnte mir in den Arsch beißen. Denn...
> Wenn dann alle Raid-Partitionen den Typ fd (= Raid-Autodetect)
> haben, kannst du vollkommen ohne Module und initrd-Image auskommen
> um den Kernel zu booten und init (Prozeß 0) zu starten.
Genau. Bei fest eincompilierten Treibern entfällt der ganze Script- und
initrd-Krempel, alles überflüssig, Partitionstyp fd langt. Ich hatte mir
das Raid nach einer Web-Anleitung gebaut, und mich nie darum gekümmert,
ob es auch noch anders ginge; bis 2.6 lief es ja, ohne daß man auch nur
ein Auge drauf hätte werfen müssen.
> Lediglich der Bootloader ist bei Softare-Raid etwas tricky, aber
> auch dazu findet sich in man lilo einiges (und im
> Software-RAID-HOWTO).
Der läuft ja bei mir prima. Mit initrd *g*.
> Zum devfs-Problem: es gibt einen Kernel-Bootparameter um das
> abzustellen, ich glaube:
> nodevfs oder
> devfs=no
> am Bootprompt. Genau weiß ich diesen nicht, vielleicht in der
> Kernel-Doku nochmal nachschauen. IMHO ist devfs bei Kernel 2.6 eh
> schon wieder "böööse".
Ich hatte es nie. Der ursprüngliche Grund für meine Beschwerde war ja,
daß mkinitrd ohne Prüfung dessen einfach von devfs ausgeht. Und das ist
wirklich böse, auch wenn man unter 2.4.x mdadm ohne devfs in einer
initrd verwenden will. Ich bin mit diesem Setup zwar ein Umstandskasper,
aber dieses Verhalten ist IMHO trotzdem ein Bug.
> Ich schicke dir per PM nochmal meine dmesg vom Bootvorgang, damit du
> mal siehst wie einfach das Raid ohne Module initialisiert und
> gebootet wird.
Ich habe da sehr neidisch drauf geschaut. Es geht also auch einfach.
Danke.
Trotzdem wieder 2.4.26. CDs brennen will ich schon, ohne daß der
SCSI-Bus resettet.
Grüße,
kro
--
Veteran of the Bermuda Triangle Expeditionary Force 1990-1951
(PGP/GPG 0xCE248A25)
Reply to: