sda und sdb wechseln sich ab

[V10lator]

Hi,
vor einiger Zeit habe ich eine SCSI Karte in meinen Rechner gebaut. Seit dem ging alles schief.
Zuerst einmal zu meinen Festplatten + externen Geräten:

Am ersten SATA Port hängt eine SSD. Diese war vor der SCSI Karte immer sda.
Am zweiten SATA Port hängt eine HDD. Vor SCSI immer sdb.
Dann habe ich noch einen Cardreader, dieser ist intern via USB angeschlossen und belegte in der guten alten Zeit immer sdc, sdd, sde und sdf (4 LUNs)

Nach Einbau der SCSI Karte (übrigens nur um einen SCSI Scanner anzuschließen) sahen die ersten paar boots (meist aber nicht immer) folgendermaßen aus:
sda = SSD
sdb - sde = Cardreader
sdf = HDD

Nun gut, dachte ich mir, ändere ich eben die /etc/fstab und lasse die HDD via UUID mounten. Gesagt getan. Außer das ich die HDD Überwachung in gkrellm ab und an per Hand nachjustieren musste funktionierte das.
Doch dann fing es an: sda wurde teilweise zu sdb oder sde, auf gut deutsch: Die sd*s tauschten teilweise wahllos ihren Platz.
Also habe ich die SCSI Karte vorerst wieder entfernt (sie soll später aber wieder benutzt werden) und hoffte das dies alle Probleme lößt. Doch weit gefehlt. Zwar bleibt der Cardreader jetzt an seinem Platz doch booten ist ein Glücksspiel, denn teilweise vertauschen sich sda und sdb. Das Ergebniss sollte bekannt sein: Der Kernel verweigert es von sda2 zu booten, denn diese Partition existiert nur auf der SSD. Die HDD hat nur eine (eig. sdb1).

Der SATA Controller ist ein ICH-7 (Kein AHCI).

Ich habe bereits sämtliche sd* Einträge in der /etc/fstab durch UUIDs ersetzt. Dies löst jedoch das Problem nicht da der Kernel immernoch sein root=/dev/sda2 Kommando von GRUB2 übergeben bekommt.

Ich frage mich wirklich was hier verhunzt ist. Da GRUB läd kann die BIOS Reihenfolge ja eig. nicht falsch sein (obwohl der MBR aus historischen Gründen sowohl auf der SSD als auch auf der HDD vorhanden ist sollte GRUB die Dateien aus /boot ja nicht nachladen können).

Eine UUID im root= Parameter mag der Kernel auch nicht und extra dafür ein initramfs aufzusetzen möchte ich ehrlich gesagt auch nicht.

//EDIT: gerade kam mir noch die Idee das der SCSI Treiber für die Karte schuld sein könnte, also habe ich ihn aus dem Kernel in ein Modul verbannt. Dies ändert aber auch nichts.

//EDIT²: SCSI Stuff im Kernel:
-*- SCSI device support
[*] legacy /proc/scsi/ support
<*> SCSI disk support
<*> SCSI CDROM support
<*> SCSI generic support
[*] Probe all LUNs on each SCSI device
[*] Asynchronous SCSI scanning
[*] SCSI low-level drivers --->
[M] Tekram DC395(U/UW/F) and DC315(U) SCSI support (EXPERIMENTAL)

[py-ro]

Es ist schlicht nicht garantiert, dass die Controller in einer bestimmten Reihenfolge erkannt werden.

Das Grub immer mit sda2 funktioniert ist im Prinzip Glück. Das sich die Reihenfolge jedesmal ändert, bei ungeänderter Konfiguration, ist zwar relativ ungewöhnlich, könnte aber z.B. daran liegen, dass beim Kaltstart einer der Controller länger zum initialisieren Brauch als bei einem Warmstart oder der SCSI-Controller den Bus evtl. nicht komplett neu scannen muss, und, und, und...

Was du machen könntest um immer konsistente Device-Nodes zu bekommen, ist mit udev-Regeln zu arbeiten und z.B. anhand der UUID der SSD immer den Node /dev/SSD zuzuweisen. Mittels Initrd könnte man auch als root= eine UUID übergeben, LABELS funktionieren mit aktuellen Kernels AFAIK auch ohne Initrd.

Das BIOS hat übrigens nichts damit zu tun, das ist raus sobald Grub den Kernel lädt.

Das sda und sdb sich vertauschen deutet daraufhin, dass diese sich an verschiedenen Controllern befinden oder das die SSD aus irgendeinem Grund nicht sofort initialisert wird, was aber seltsam wäre, da der Kernel ja von dort geladen wird, vermute ich.

Ich hoffe ich habe ein paar Denkanstöße gegeben.

Py

[V10lator]

Sowohl die SSD als auch die HDD hängen am ICH-7 welcher auf dem Mainboard verbaut ist.
Du hast auch recht damit das der Kernel von der SSD geladen wird. /boot = (normlerweise) sda1, root sda2.
Sachen wie /var/tmp /usr/portage /home usw. sind dann auf der HDD, das ist in diesem Fall aber unwichtig da der boot ja lange vorher abbricht.
Auch udev kann mir nicht helfen, denn udev liegt auf sda2. Doch wie soll udev von sda2 geladen werden wenn der kernel sda2 nicht findet?

Das mit dem LABEL werde ich sofort testen. Ich schätze der Parameter müsste in etwa folgendermaßen aussehen: root=LABEL=foo ?

//EDIT: Weder root=LABEL=root noch root=root funktionieren. Kennst jemand zufällig den genauen Parameter und/oder weiß ab welchem Kernel das möglich ist (oder noch besser: Hat den entsprechenden Patch zur Hand)?

[Josef.95]

Du könntest es ja erst mal mit einer initrd testen ;)
So eine initrd ist zb mithilfe der genkernel Skripte schnell und einfach erstellt

[firefly]

ab 2.6.36 oder 2.6.37 hat der kernel support für Partition UUIDs als angabe für die root parition. Nur anscheinend funktioniert dies aber nur mit EFI parittiions tabellen, welche LABEL/UUID für paritiionen unterstützen.
Die UUID/LABEL, was man schon seit längeren beim formatieren einer paritition angeben kann werden AFAIK im Dateisystem abgelegt und dies scheint der Kernel nicht auszuwerten ohne eine initrd.

siehe: http://www.linux-archive.org/gentoo-user/481167-mounting-root-partition-uuid-no-initrd-needed.html
_________________
Ein Ring, sie zu knechten, sie alle zu finden,
Ins Dunkel zu treiben und ewig zu binden
Im Lande Mordor, wo die Schatten drohn.

[V10lator]

Danke für all die Tipps.
Aber die Partitionstabelle umzuwandeln ist mir ehrlich gesagt zu riskant. Unter anderem auch weil ich nicht weiß wie die SSD Firmware damit zurechtkommen würde. Theoretisch sollte sie zwar keine Zicken machen aber Theorie und Praxis unterscheiden sich ja leider oft.

Genkernel benutze ich nicht. Soweit ich weiß ist das ja auch ein eigener Kernel. Kann ich das einfach installieren und trotzdem problemlos sys-kernel/gentoo-kernel nutzen?

//EDIT: Ich habe mir jetzt mal nach dieser Anleitung ein initramfs erstellt, nur das ich gzip -9 durch lzma -9 -e -z -c - ersetzt habe (der Kernel hat Support für lzma komrimiertes initramfs).
Aktuell kompiliert der Kernel (mit devtmpfs Unterstützung). Ich melde mich wieder sobald alles fertig und getestet ist.

//EDIT²: Auch wenn ich es immernoch etwas unschön finde dafür ein initramfs zu verwenden scheint es zu funktionieren.
Danke noch mal an alle