Sorry, daß ich mich erst jetzt melde. Ich kam endlich mal dazu ein Testsystem
fertigzumachen.
Also ich bin auf ähnliche Probleme gestoßen wie du (wollte ich ja auch), aber
letztendlich funktioniert alles.
Ich hatte eine VM mit: 1 HD am IDE-Bus, 4 x SCSI am SCSI-Controller.
Die Install-CD zeigt das gleiche Bild wie bei dir, also:
sda-d die 4 SCSI-Platten
sde die IDE-Platte, die nicht ins raid soll und die / werden soll.
Das System ganz normal auf /dev/sde1 installiert. Auch den Grub über den Installer
in den MBR von sde. (das wäre auch hier hd4,0).
Beim ersten Boot der gleiche Grub-Fehler wie bei dir. Mit root(hd4,0) wird der
Kernel nicht gefunden. Meine Tips mit dem Mapping bringen hier nichts.
Grub umgestellt auf root(hd0,0) funktioniert - wie bei dir auch.
Das Verhalten ist klar, aber für die späteren Aktionen ist es kein Beinbruch das so
zu machen (root hd0,0).
Grub bekommt vom BIOS die IDE-Platte (in deinem Fall die SATA am onboard-Kontroller)
halt als erste Platte päsentiert. Erst der Kernel bewirkt eine andere Reihenfolge, bei der
dann eben diese Platte zur "Letzten", sde, wird.
Ich könnte in meiner VM IMHO die Reihenfolge der Kontroller umstellen, auch könnte
man in den relvanten dateien (grub, fstab,etc) mit UUIDs anstatt der (wechselnden)
Device-Namen(sdXYZ) arbeiten. Das ist aber (auch bei dir) nicht nötig.
Nötig ist Grub nur beim Boot zusagen: (hd0,0). Wenn der Kernel dann in Aktion
tritt ist Grub schon längst wieder in der Versenkung und wird fürderhin auch nicht
mehr gebraucht.
Zum Raid5:
habe ich also aus sd[abcd]1 erstellt. Kein Problem.
Lediglich das mit der einen "fehlerhaften" beim initialen Sync hatte ich auch.
Normal habe ich eher mit Raid10 zu tun, bei mdadm ist das bei Raid5 aber normal.
Aus der man page:
Normally mdadm will not allow creation of an
array with only one device, and will try to create a raid5 array
with one missing drive (as this makes the initial resync work faster)
Also lediglich zur Geschwindigkeitsoptimierung wird eine Platte beim initialen
Sync "abgeschaltet". Nachdem mein sync durch war, waren auch alle 4 Platten
up (UUUU).
So, warum klappt bei dir der Sync nicht?
Du kriegst eine kernel panic (so daß nur noch der Reset-Knopf hilft)? Oder nur
einen sog. Trap?
Ich hatte ja die Vermutung, daß durch das o.a. "Reihenfolgeproblem" evtl. eine
falsche Platte genommen würde oder ähnliches. Das ist aber (auch bei dir) nicht
der Fall.
Ich tippe ganz stark auf ein Hardware-Problem. Entweder der Controller, eine Platte
oder ein Kabel.
Natürlich käme auch noch der Kernel-Treiber in Frage (Software).
Überprüfe doch mal alle Kabel auf festen Sitz.
Das Netzteil ist ok und ausreichend dimensioniert für alle Geräte?
Kein Hitzeproblem im Rechner?
Um rauszukriegen, ob es evtl. eine ganz bestimmte Platte/Kabel ist:
Klemme eine Platte ab und erstelle dir das Raid5 halt mit 3 Platten (ist ja die
Minimalanzahl bei Raid5).
Wenn der Sync dann funktioniert hast du evtl. schon die Problem-Platte/Kabel gefunden.
Ansonsten halt eine der 3 abklemmen und die vorher abgeklemmte als Dritte nehmen.
Und so fort...
Wie gesagt: am Konzept und deinem Vorgehen ist alles richtig.
Ich tippe zu 80% auf die Hardware, 20% bleiben für Kernel-Treiber 😉
Beim evtl. testen mit dem Raid und Reboot immer daran denken, die mdadm.conf
anzupassen damit da evtl. nicht noch ein alter ARRAY-Eintrag drinsteht.
Aber zum testen ob das Sync mit 3 Platten klappt mußt du nicht jedesmal
Rebooten (außer halt wieder bei einer kernel panic)...
Wenn ich dir noch mit etwas helfen kann melde dich ruhig.
//Edit, Nachtrag:
erhalte immer einen kernel panic wenn der sync vorgang des raid zu ende ist
Ist er da wirklich am Ende (99/100%) oder noch mittendrin gewesen? Ungefähr immer
beim gleichen Prozentsatz mittendrin oder wechselte das?
Eine Option wäre auch noch (wenn obiges nichts bringt):
"mdadm --create --force /dev/md0 ..."
Mit force wird das Auslassen/Abschalten der einen Platte unterdrückt.