Hallo Jürgen,

nach einem Upgrade meiner 9.2 auf 9.3 konnte das System nach dem Upgrade der Packages nicht mehr booten. Das System bleibt mit folgender Fehlermeldung stehen:

Wating for device /dev/root to appear: . ok rootfs: major=3 minor=1 devn=769 Mounting root /dev/root mount: No such device umount2: Device or resource busy Kernel panic - not syncing: Attempted to kill init!

Das Booten von CD (Option "Installiertes System Booten") bleibt ebenfalls an dieser Stelle hängen. Wenn ich die Rescue CD boote, läßt sich /dev/hda1 problemlos mounten. Ich hab auch schon manuell die initrd erstellt und mit lilo den Bootsector aktualisiert, alles erfolglos :-(((

Eventuell hat das mit einem Fehler im Installationsskript von SuSE-9.3 zu tun: 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. Grüsse, Markus