Hallo Jörg,

Mal kurz eine Beschreibung des Systems unter 9.2: Mainboard ist ein MSI mit Onboard Promise. Die 4 Platten am Promise werden als hda-d erkennt, die Platten am Standard IDE Kontroller als hde/f. Das hat sich bei 9.3 auch nicht geändert.

Ich habe ebenfalls ein MSI mit Onboard-Promise und aehnliche Probleme (wenn auch meine Plattenaufteilung ganz anders ist). Die Ursache liegt meines Erachtens in einem Fehler im Installationsskript von SuSE-9.3: Bei Boards mit VIA-Chipsatz und PromiseController kann es bei der Installation bzw. beim Update auf SuSE-9.3 zu ernsten Boot-Problemen kommen, wenn sowohl an den OnBoard-IDE-Kanaelen (/dev/hda,b,c,d) als auch am PromiseController (/dev/hde,f,g,h) Festplatten angeschlossen sind. In solchen Fällen vertauscht die initrd der SuSE-9.3 die IDE-Kanaele (z.B. 1.Festplatte am 1.IDE-Kanal wird zu /dev/hde statt /dev/hda und die 2.Festplatte am PromiseController wird zu /dev/hda statt /dev/hde). Auch der von manchen verwendete Boot-Parameter 'ide=reverse' funktioniert bei der mitgelieferten initrd nicht mehr. Moegliche Folgen sind: a) eine Erst-Installation fuehrt falsche Device-Namen ein :-/ b) ein Update von einer fruehren SuSE-Installation findet die root-Partition nicht (kein Update moeglich) :-( c) der Initial-Boot (1.Boot nach Installation/Update) bleibt mit 'waiting for root device' oder 'kernel panic' haengen :-(( d) Bei einem System mit Festplatte(n) nur am OnBoard-IDE wird zunaechst alles gut gehen. Erweitert man aber spaeter einmal sein System um eine zusaetzliche Festplatte am Promise, so wird die SuSE-9.3 nicht mehr booten, da sie die root-Partition dann auf der neuen Platte sucht :-( Ausgangspunkt des Debakels ist der Umstand, dass im mitgelieferten Kernel vmlinuz-2.6.11.4-20a-default (vielleicht steht ja 'a' fuer 'alpha'?) die IDE-Treiber (kernel CONFIGS_IDE/IDE_GENERIC/BLK_DEV_IDE) nicht mehr in den Kernel eincompiliert sind, sondern als Module nachgeladen werden. Das ist an sich eine gute Idee und das Installationsskript findet auch die richtigen Kernel-Module (also z.B. 'via82cxxx' und 'pdc202xx_old'). Das Problem ist nur, dass die Reihenfolge wie die Module geladen werden nicht egal ist, das Installationsskript die aber offenbar alphabetisch sortiert: Also "pdc202xx_old via82cxxx" statt "via82cxxx pdc202xx_old" Dadurch sieht die Initial-Ramdisk zuerst den PromiseController und erst danach die OnBoard IDE-Kanaele ! (wahrscheinlich geht das auch bei Boards mit SYS-Chipsatz schief - 'sys' kommt ja nach 'pdc' - wobei INTEL-Chipsaetze wohl nicht betroffen sind) Bloed auch, dass man den Verdreher am Boot-Prompt nicht mehr umdefinieren kann, da z.B. der Kernel-Parameter 'ide=reverse' zu spaet kommt (die Vertauschung ist ja schon durch die initrd passiert, welche erst den Kernel nachlaedt). Loesungsvorschlag: 1) Fuer die Installationen/Update den Boot-Parameter 'insmod=ide-generic' verwenden. Dadurch ist die Installation geringfuegig langsamer, findet aber die Festplatten erst mal in der richtigen Reihenfolge. 2) Falls nun der Initial-Boot die gerade eingerichtete root-Partition nicht mehr findet: keine Panik! 3) Zwar funktioniert der 'insmod=ide-generic' nur fuer die Installation, aber man kann einfach wieder von der Installations-CD booten, dort zunaechst wieder 'Installation' mit 'insmod=ide-generic' waehlen, dann aber bei der Folge-Abfrage NeuInstallation/Update/SystemBooten auf 'vorhandenes System Booten' gehen. Auf diese Weise schlaegt die Installationsprozedur die richtige root-partition vor (z.B. /dev/hda7) und man kann ganz normal durchbooten. 4) damit man nun (3) nicht bei jedem Boot durchexerzieren muss aendert man die initrd-Modul-Reihenfolge in /etc/sysconfig/kernel, also z.B.: INITRD_MODULES="pdc202xx_old via82cxxx scsi_mod sd_mod reiserfs" in INITRD_MODULES="via82cxxx pdc202xx_old scsi_mod sd_mod reiserfs" anschliessend erzeugt man mit mkinitrd eine neue InitialRamDisk und ab dem naechsten Boot ist alles o.k. (auch ein zukuenftiger Kernel- Update sollte gut gehen, da dieser ja die INITRD_MODULES Reihenfolge in /etc/sysconfig/kernel nicht mehr aendert. Vielleicht gehts auch noch einfacher, aber fuer mich waren die obigen Punkte 1-4 die Erloesung eines langen Wochenendes. P.S.: Der 'kostenlose' SUSE-Support hat uebrigens bei meiner Anfrage gleich abgeblockt, da ein PromiseController wohl grundsaetzlich unter 'Raid-Verdacht' steht und Raid-Support nicht kostenlos ist ?! Dabei wollte ich ja gerade NICHT von den Promise-Platten booten, sondern habe nach einer Loesung gesucht, wie ich (ganz simpel) von der 1.Disk booten kann ohne die PromisPlatten zu benutzen. Offenbar sind seit dem Wechsel zu Novell nur noch Trivialfragen 'kostenlos'. Gruss, Markus