FATAL Could not load /dep/modules nach Update

Hallo,

ich habe vor 2 Tagen ein Update meines Systems Suse 12.3 mit zypper up vorgenommen. Nach dem Neustarten kommt die Maschine nicht mehr hoch. Sie bricht den Bootvorgang mit FATAL: Could not load /lib/modules/3.7.10-1.28-desktop-modules.dep ab. Ich lande dann in einer Konsole, die nichts kann.
Da in meinem /boot auch noch die Kernel 3.7.10-1.16 und 3.7.10-1.1 liegen, habe ich versucht, diese von der GRUB Konsole aus zu starten mit root (hd0,1);kernel ... ; initrd ... ; boot
Ich bekomme hier einen anderen Fehler: Kernel panic - not syncing: Unable to mount root fs on unkown-block (0,0). Hier kommt keine Konsole, sondern der Rechner steht.

Was kann ich tun, um wieder zu booten? Warum passiert das überhaupt?

Ein Hinweis im Netz war, dass die modules.dep in der ramdisk fehlt. Schön, aber wie bekomm ich die dort rein und warum ist die nicht drin? Abgesehen davon, dass ich das nicht prüfen kann.

Zur Konfig:
Das System enthält 2x2 Platten im Software-Raid1 und eine Backupplatte. Auf den RAID-Laufwerken läuft LVM2. Die Systempartition (/ und /boot) liegen allerdings auf /dev/mdX und nicht im LVM. Ich kann nicht von CD/DVD booten (z. B: Rescue), weil das Board wohl nur von den ersten 4 Ports gebootet werden kann und ich keine der Raid-Platten abziehen wollte.

Vielleicht hat ja einer eine IDee, was zu tun ist?!

Danke

Nachtrag:
Ich kann über eine angeschlossene USB-DVD SuSE Rescue laden. Allerdings nicht die Option "Boot from local disk" benutzen, diese hängt.
Leider weiß ich nicht, was ich mit dieser Möglichkeit anstellen kann...

Daß beim Update etwas schiefgelaufen ist, lasse ich mir ja einreden (ich denke da z. B. an eine aus Platzmangel unvollständige initrd, denn wer liest schon Installationsprotokolle?), aber auf die bisherigen Kernel und initrd hat das ja keinen Einfluß. Angaben wie

FuenfAsse schrieb:

root (hd0,1);kernel ... ; initrd ... ; boot

Zum Vergrößern anklicken....

lassen mögliche Formalfehler nicht erkennen. Wurde der Parameter "root=" verwendet? Wurde dabei das raid device angegeben? Wurde es ohne diesen Parameter probiert (die Systempartition ist ohnehin in der initrd definiert)?

FuenfAsse schrieb:

Leider weiß ich nicht, was ich mit dieser Möglichkeit anstellen kann.

Zum Vergrößern anklicken....

Im Rettungssystem meldest Du Dich als root (ohne Paßwort) an und prüfst die Boot- und die Systempartition, bei Ext2/3/4 mit (eventuell mußt Du vorher ausführen). Ein sollte keine Auffälligkeiten zeigen.

Hallo,

Freier Speicher der Boot-Partition 3.6GB, Root-Partition 12GB. Die Partitionen sind sauber.
Bei Zypper sieht man eigentlich recht gut, ob es durchgelaufen ist. Mir ist nichts aufgefallen und es ist ja nicht mein erstes Update. Alle VMs auf dem System sind ordentlich durchgelaufen. Die haben aber auch md und LVM. Vielleicht liegt es auch daran. Ich kenne jemanden, der hat nach dem Update wohl ein ähnliches Problem.
Und hier gibt es auch was zum Thema md: https://bugzilla.novell.com/show_bug.cgi?id=851993.

Im Boot Menü ist root=/dev/md2 eingetragen. Das sollte aber beim Start aus der Konsole keine Rolle spielen, oder?

Ich halte mich erstmal an die Fehlermeldung "fehlende modules.dep":
Beim Einhängen von / ins live-System ist mir aufgefallen, dass dort keine /lib/modules/3.7.10-1.28-desktop/modules.dep existiert. Auch in der zugehörigen initrd finde ich keine. Würde mich nicht wundern, wenns daran liegt.
Nur: Wie erstelle ich die Datei jetzt bei dem aktuellen Systemzustand? Ich werde mal chroot probieren und depmod -a !? In der Hoffnung, dass es keine Rolle spielt, welche Kernel gerade läuft.

Ich bin für jede Unterstützung dankbar.

So, nun gehts wieder. Die fehlende modules.dep war wirklich die Ursache.
Folgendes führte bei mir zum Ziel. Vielleicht hilft es ja jemandem.

1. Suse live cd booten.
2. chroot-Umgebung erzeugen (geht wahrscheinlich ohne, aber mkinitrd ist vielleicht einfacher so)
- Verzeichnis erzeugen: /wirt
- Root-Partition des Wirts dahin mounten. Das live system mappt die md anders als mein Wirt. /dev/md126 statt /dev/md2, also link angelegt und gemountet.
- /dev, /dev/pts, /proc, /sys mit mount --bind unter -wirt einhängen
- chroot /wirt /bin/bash
3. Der folgende Schritt ist vermutlich speziell für meine Situation: Ich hatte VMs auf dem System, die zuvor erfoglreich booten konnten. Von dort habe ich mir die modules.dep geholt. Es geht vermutlich auch eine andere Quelle. Das Live System ging nicht, da es den Kernel 3.7.10-1.1 benutzt. mkinitrd und depmod -a funktionieren nicht, weil sie die aktuell laufende Kernelversion verwenden. Ich habe auch nicht herausgefunden, ob man depmod auf einen kernel anwenden kann, der nicht gerade läuft. Das würde vieles vereinfachen.
- Bei mir liegen die VMs als raw in LVM logical volumes. Im live system muss man erst mit vgchange -ay die volumes aktivieren. Danach kann man sie mounten.
- Jetzt mit kpartx -a /dev/<vg>/<lv> die Partitionen mountbar machen.
- nun mounten: mount /dev/mapper/<vg>-<lv>2 /mnt . (Die 2 heisst bei mir, dass die 2. Partition im raw die root-Partition ist)
- Jetzt mit cp -i /mnt/lib/modules/3.7.10-1.28-desktop/mod* /wirt/lib/modules/3.7.10-1.28-desktop/mod* auf den Wirt kopieren.
4. In der chroot-Umgebung mkinitrd -d /dev/md2 aufrufen.
5. Live system beenden
6. Wirt booten. Geht.
7. depmod -a ausführen, um sicher zu sein, dass die modules.dep auch passt. Ein neuerliches mkinitrd ist vermutlich auch nicht schlecht.

Tja, wie kann ich verhindern, dass es beim nächsten Update wieder passiert!? depmod -a nach zypper up wird nicht gehen, da da ja noch der alte Kernel läuft.

FuenfAsse schrieb:

mkinitrd und depmod -a funktionieren nicht, weil sie die aktuell laufende Kernelversion verwenden.

Zum Vergrößern anklicken....

Nach erfolgreichem chroot sollte funktionieren.

FuenfAsse schrieb:

wie kann ich verhindern, dass es beim nächsten Update wieder passiert

Zum Vergrößern anklicken....

Gibt es in /var/log/zypp/history zum Zeitpunkt des Kernel-Update irgendwelche Besonderheiten? Kommt bei (außer gegebenenfalls der Datei /etc/modprobe.d/99-local.conf) etwas heraus?

P. S. Beim Punkt 2. fehlt das Einhängen der Boot-Partition.