[Eisfair_dev] E1 Busybox und Raid

Thomas Zweifel t2fel at gmx.net
Mo Jan 5 09:26:54 CET 2015


Hallo Thomas

Am 30.12.2014 um 21:06 schrieb Thomas Bork:
> Am 24.12.2014 um 15:59 schrieb Thomas Zweifel:
> 
>>       ....ich hatte es auf mein Vorhaben mit dem lvm bezogen, dadurch
>> werde ich in Zukunft ein paar mal weniger oft den kernel laden müssen,
>> allerdings werden es andere nach wie vor tun - weils nicht anders geht.
> 
> Stimmt nicht, Du kannst nach Änderungen händisch eine neue initrd erzeugen.

Ein Punkt für dich!
Aber warum sollte man sowas tun müssen? ;-)


> Folgendes Problem wirst Du immer haben:
> Legst Du ein Raid an, auf dem das System liegt, werden bereits in der
> initrd Programme und Treiber benötigt, um den Zugriff auf das System zu
> ermöglichen - sonst kommt das System nicht mehr hoch und das Boot-Skript
> wird auch nicht mehr ausgeführt.

Das habe ich nirgends behauptet, es ging mir von Anfang an nur um
zusätzliche md für Daten.


> Sieh es als Design-Entscheidung, dass Raids demzufolge in der initrd
> assembliert werden, um immer zu gewährleisten, dass das System hoch
> kommt. Daraus folgt, dass bei Raid-Änderungen eine neue initrd erzeugt
> werden muss.

Ein Zweitaufruf des mdadm vor dem fsck setzt die in der initrd fehlenden
md anhand der aktuellen mdadm.conf zusammen. Nicht Mehr und nicht Weniger.

An der Stelle ist eure 'Design-Entscheidung' IMHO ziemlich unausgegoren.
Ihr lasst die User eine mdadm.conf mühsam aus Einzelteilen
zusammenfrickeln, und nutzt die Datei danach noch nicht einmal. :-(

Den mdadm Menupunkt könnte man in dem Zusammenhang deutlich
entschlacken. ;-)


> Wir machen das ausschließlich
> im Kernel-Update (ich hatte nicht genügend Zeit, die komplette Funktion
> auszulagern).

Das kann auch so bleiben.



Gruss Thomas


Mehr Informationen über die Mailingliste Eisfair_dev