Arch Linux

Kernel: unable to find root device

Antoras

Hallo,

ich habe nach einem Komplettupdate meines Systems das Problem, dass mein Kernel mein root device nicht mehr starten kann bzw. findet.

Fehler:

:: Starting udevd
done.
:: Running Hook [udev]
:: Triggering uevents...done.
Waiting 10 seconds for device /dev/sda3 ...
ERROR: device '/dev/sda3' not found. Skipping fsck.
ERROR: Unable to find root device '/dev/sda3'.
You are being dropped to a recovery shell

/dev/sda3 ist meine root-Partition. Den Fehler scheinen schon einige andere Leute auch bekommen zu haben. Ich hab einige Themen dazu gefunden, die Lösungsvorschläge dazu waren in der Art: Kernel/udev/mkinitcpio ist defekt und muss neu installiert werden.

kernel 3.2.4 unable to find root device
Unable to find root device - after updating

Das habe ich gemacht - gebracht hat es aber nichts. Selbst nach einem Downgrade des Kernels kam die Fehlermeldung.

"mkinitcpio -p linux" brachte ein paar Warnungen wie "errors were encountered during the build. The image may not be complete.", die aber scheinbar keine weiteren Auswirkungen hatten.

Zur Sicherheit habe ich in der menu.lst von GRUB die UUID der root-Partition eingetragen um auszuschließen, dass er mit der Bootreihenfolge durcheinander kommt. Aber auch das brachte keine Besserung. Jetzt sieht es dort ungefähr so aus:

# (0) Arch Linux
title  Arch Linux
root   (hd0,0)
kernel /vmlinuz-linux root=/dev/disk/by-uuid/<UUID_of_root_device> ro vga=773
initrd /initramfs-linux.img

/boot liegt auf einer eigenen Partition (nämlich sda1) und ist ext2 formatiert. / ist ext4.

Ich bin überfragt was man noch ändern könnte, damit der Kernel das root device wieder findet. Hat jemand Vorschläge?

GerBra

Antoras schrieb "mkinitcpio -p linux" brachte ein paar Warnungen wie "errors were encountered during the build. The image may not be complete.", die aber scheinbar keine weiteren Auswirkungen hatten.

LOL ;-)
Scheinbar?

man mkinitcpio
Suche nach verbose
Poste/(verstehe ggf.) den Output davon....

Antoras

Im verbose ouptut kann ich nichts besonderes erkennen. Dort erscheinen nur logs über die geladenen symlinks/dirs/files/modules. Die Warnung wird nicht einmal mitgeloggt. Dabei hab ich aber noch einen anderen Fehler entdeckt. Es erscheint die Meldung "cp: inavalid option -- 't'". Könnte die vllt. etwas zu bedeuten haben? Laut timestamp der Dateien aus /boot werden die beiden *.img immer zur korrekten Zeit erstellt.

Hab den Log von mkinitcpio aber mal hochgeladen:
http://www.file-upload.net/download-4236649/mkinitcpio-out.html

GerBra

Das mkinitcpio Log sieht gut aus. Die Fehlermeldungen, die du kriegst: Nach bzw. bei welchen Hooks treten die den auf?

Du hast einen Boot sicher auch schon mal mit dem Fallback-Image versucht?

Wenn das (devicefile) /dev/sda(3) nicht gefunden wird, dann ist eigentlich entweder das notwendige Modul für den Buscontroller nicht geladen bzw. generell bei udev "hakt" etwas.
Ich würde nun so vorgehen:
a) Fallback Boot versuchen
b) Boot-Logging erweitern und sehen, ob in der initrd+busybox wirklich kein Blockdevice "erzeugt" wird.
Dafür würde ich die Kernelzeile im Bootloader so aufbauen:

kernel /vmlinuz-linux root=/dev/sda3 ro rootdelay=10 debug ignore_loglevel break=y

(Das break=y kannst du dir wohl schenken, du wirst ja automatisch in die busybox Shell geschickt...
Durch das Debugging-Output kannst du nun mit SHIFT+BILD-Hoch bzw SHIFT+BILD-Runter durch die Logmeldungen blättern. Normalerweise tauchen da schon Meldungen/Hinweise auf gefundene Blockdevices etc. auf. Und eben ggf. auch Dinge die wie "Fehelrmeldungen" aussehen... Da du ja nicht ohne grund in der Busybox landest sollten sich entsprechende Debugmeldungen eigentlich ziemlich "unten" finden lassen...

Weiterhin könntest du mit blkid schauen, welche Blockdevices/Partitionen denn gefunden würden, ob sich ggf. nur die Bezeichner geändert haben.
Auch ein:

udevadm --debug trigger

sollte gegen Ende eigentlich etwas von /devices/pci12345555/ataXY.... zeigen für Blockdevices/Partitionen...
Mit lsmod kannst du ggf. nachschauen, ob das Modul für den Bus-Controller geladen wäre:
lsmod | grep ahci
z.B. wenn du einen Sata-Controller hast..
Ebenfalls kannst du mit ls mal im /dev rumschauen, gerade dort wo eigentlich die Blockdevices sich "tummeln" (sollten):

ls /dev/sd*
ls /dev/disk/by-id/

ob dort deine Festplatte(n) auftauchen.

c) Wenn das Debuggen nichst erhellendes bringt schau ggf. im /var/log/pacman.log nach, was zuzüglich des Kernels noch an Updates kam. Kandidaten für Downgrades wäre mit Sicherheit udev und mkinitcpio selbst...

Welche Hardware (Bus-Controller(Sata,IDE;SCSI)?, Festplatten) sind denn in dem Rechner? Keine externen HDs, USB-Sticks, Cardreader-Speicher mehr im Rechner?

Antoras

Die Warnung tritt immer unmittelbar auf bevor die Meldung kommt, dass das Image erfolgreich erzeugt werden konnte. Der Fehler bei cp erscheint nach dem Hook fsck (dem letzten zu parsenden Hook). Fallback-Image bringt natürlich nichts.

Beim Starten von einer Live-CD bekomme ich übrigens auch eine Fehlermeldung beim Booten: "Waiting 30 seconds for device /dev/disk/by-label/ARCH_201108 ..."
Nach der Eingabe von "udevadm trigger" kann allerdings normal weitergebootet werden. Nur falls es da vllt. irgendeinen Zusammenhang geben könnte.

Wenn ich den Kernel auf meiner Platte boote, kann ich in der Recovery-Shell mit der Tastatur keine Eingaben tätigen. Besondere Fehlermeldungen kann ich in den Debug-Meldungen auch nicht erkennen. Zuletzt erscheinen die Meldungen:

[1.3] Refined TSC clocksource calibration 3003.381 MHz
[1.3] Switching to clocksource tsc

Zuvor erscheinen zwar ein paar "negative" LogMeldungen, allerdings glaube ich nicht, dass die irgendetwas mit dem Problem zu tun haben. Da wäre z.B.:

[0.6] ERST: Table is not found!
[0.6] GHES: HEST is not enabled!

Die Timestamps in den [] habe ich vereinfacht

In den Hooks der /etc/mkinitcpio.rc steht folgendes:

HOOKS="base udev autodetect pata scsi sata filesystems usbinput fsck"

Die restlichen Datensätze sind leer. Ich habe autodetect auch schon deaktiviert, in der Hoffnung, das es etwas bringt und mein Keyboard daraufhin geladen wird. Aber Fehlanzeige.

GerBra

Antoras schriebDie Warnung tritt immer unmittelbar auf bevor die Meldung kommt, dass das Image erfolgreich erzeugt werden konnte. Der Fehler bei cp erscheint nach dem Hook fsck (dem letzten zu parsenden Hook).

Dann müßte man mal deine komplette /etc/mkinicpio.conf sehen.
Der einzige Punkt, bei dem in mkinitcpio cp genutzt wird ist, wenn Module zum initrd kopiert werden.

Wenn ein Downgrade (auf eine version, die definitiv schon mal funktionierte) auch nichts brachte liegt die Vermutung ja nahe, daß die Usache im Verfahren zur herstellung des initrd-Images liegt, also mkinitcpio+Config.

Das die Arch-Cd auch nicht funktioniert (timeout 30s): Du hast wohl einen der Rechner, bei denen diese mysteriöse Erscheinung auftritt. Ob das nun auch Auswirkung aufs aktuelle Problem hat weiß ich so ad hoc nicht...
Wenn du in der busybox/Rettungsshell nun keine tastatur hast: Gibt es in deinem Rechner im BIOS eine Option mit legacy USB o.ä.? Die ggf. mal anschalten...

Ich hätte dir noch geraten über eine Live-CD und chroot den linux-lts Kernel zu installieren (damit du ggf. das System normals booten könntest). Da dafür aber auch ein funktioneirendes mkinitcpio-Lauf gebraucht wird setze ich da wenig Hoffnung draus.

Poste mal dene mkinitcpio.conf (oder teste mal mit der mknitcpio.conf.pacnew, also einer jungfräulichen, ohne ggf. eigene Module etc...)

//Edit:
Poste bitte auch noch mal von/aus deinem normalen System:
grep xargs /usr/bin/mkinitcpio

Antoras

Wie gesagt, in meiner mkinitcpio.conf steht nichts außer der Zeile mit den Hooks. Der Rest ist entweder auskommentiert oder leer.

http://www.file-upload.net/download-4244400/mkinitcpio.conf.html

Eine zusätzliche mkinitcpio.conf.pacnew existiert gar nicht und lagacy USB ist im BIOS auch schon aktiviert.

#grep xargs /usr/bin/mkinitcpio
xargs -0 cp -t "$BUILDROOT/lib/modules/$KERNELVERSION/kernel"

Da ist das -t. Ich hab keine Ahnung was das Script dort machen möchte kann es also nicht selber fixen. Ein einfachen entfernen von -t bringt: "cp: copying multiple files, but last argument '/lib/modules/3.2.6-2-ARCH/kernel/sound/soundcore.ko.gz' is not a directory".

Der Befehl steht in folgendem Kontext:

if (( ${#ADDED_MODULES[*]} )); then
    printf '%s\0' "${MODPATHS[@]}" | sort -zu |
        xargs -0 cp -t "$BUILDROOT/lib/modules/$KERNELVERSION/kernel"

    # unzip modules prior to recompression
    gzip -dr "$BUILDROOT/lib/modules/$KERNELVERSION/kernel"

    msg "Generating module dependencies"
    install -m644 -t "$BUILDROOT/lib/modules/$KERNELVERSION" \
        "$BASEDIR/lib/modules/$KERNELVERSION"/modules.{builtin,order}
    depmod -b "$BUILDROOT" "${KERNELVERSION}"

    # remove all non-binary module.* files (except devname for on-demand module loading)
    rm "$BUILDROOT/lib/modules/$KERNELVERSION"/modules.!(*.bin|devname)

else
    warning "No modules were added to the image. This is probably not what you want."
fi

GerBra

Ok, sieht alles gut aus, eigentlich.

Die cp -t Option/Syntax ist so genau richtig in mkinitcpio (Genau das wollte ich sehen...)
Damit wir die Fehler auch mal zu Gesicht kriegen bei mkinitcpio, mach mal folgendes und stelle beide Ausgaben mal bei file-upload rein:

mkinitcpio -v -g /boot/initramfs-linux.img &> /tmp/mk.log

Das schreibt die verbose Ausgabe inkl. der Fehlermeldungen nach /tmp/mk.log (Du siehst keine Ausgabe im Terminal). Diese /tmp/mk.log posten.

bash -x mkinitcpio -v -g /boot/initramfs-linux.img &> /tmp/mk1.log

Das macht das Gleiche nochmal, allerdings gibt es jeden Vorgang der bash (mkinitcpio ist ja bash) erweitert aus. Das /tmp/mk1.log auch mal hochladen....

//Edit: das ganze halt in deinem System bzw. im chroot wenn von Live-CD.
Um zu sehen ob alles funktioneirt (ob du die fehelrmeldungen auch kriegst etc.) kannst du ja erstmal einen trockenlauf ohne Ausgabeumleitung machen:

mkinitcpio -v -g /boot/initramfs-linux.img

Antoras

file-upload scheint gerade kaputt zu sein, hab die Dateien woanders hochgeladen:

mk.log
mk1.log

GerBra

Sorry, hatte ich vergessen zu erwähnen:
Wenn du mit der Live-CD bootest und mußt du die Kernelversion für das initrd mit angeben. So wurde jetzt versucht Module für den 3.0 kernel zu finden, diese sind in deinem chroot-Kernel mit Sicherheit nicht...

Deshalb beides bitte nochmal, aber ergänzt jeweils so:

mkinitcpio -v -k 3.2.9-1-ARCH -g /boot/initramfs-linux.img &> /tmp/mk.log
bash -x mkinitcpio -v -k 3.2.9-1-ARCH -g /boot/initramfs-linux.img &> /tmp/mk1.log

Hier also explizit für 3.2.9-1-ARCH (deine gewünschte Kernelversion mußt du schauen, i.d.R. die höchste in /lib/modules/)
Ansonsten kommt es halt zu dieser meldung:
==> WARNING: No modules were added to the image. This is probably not what you want.

Um in einem chroot das initrd zu bauen mußt du auch diverse virtuelle Dateisysteme(dev,proc,sys) bind-Mounten, daß weißt/machst du?
Ansonsten verrät dir das Wiki mehr....

//Edit: https://wiki.archlinux.org/index.php/Chroot
Kommt dein nichtfunktioneirendes initrd evt. davon, daß du im chroot ohne das -k für die *Kernelversion des Systes im chroot* gebaut hast? Und ggf. ohne proc,sys,dev bind-zu mounten?

Antoras

Ok, hier sind die neuen Dateien. Ich hab mit Kernel Version 3.2.6-2 gebaut. Der neueste 3.2.13-1 ist die Version, die die Probleme erst verursacht hat.

mk.log
mk1.log

Verzeichnisse (dev,proc,sys,boot) sind alle korrekt gemountet, daran sollte es also nicht liegen.

Ich hab in chroot bisher immer ohne den Parameter -k gebaut. Wenn ich das weglasse wird die gleiche Version, wie die bereits installierte Version gebaut. Also bei mir gerade 3.2.6-2, die ich am Anfang über pacman per Downgrade installiert habe.

GerBra

Es liegt IMHO wirklich am cp Befehl...
Dieses cp kennt die -t Option nicht.....

Was sagt den in der Umgebung in der du das initrd baust ein:
which cp

//Edit:
Bzw. würde das funktioneiren:

mkdir /tmp/nn
printf "/bin/date" | xargs -0 cp -t /tmp/nn

Antoras

Super, dann ist der Fehler jetzt gefunden. Nun läuft wieder alles einwandfrei. Zur Erklärung was den Fehler verursacht hat:

Ich verwende nicht die offizielle Version von cp, sondern eine gepatchte Variante, die eine Progress-Bar unterstützt. Diese scheint das -t Argument nicht zu kennen. Nachdem ich meine gepatchte Version durch die offizielle ersetzt hat konnte ich den Kernel wieder erfolgreich bauen.

Da ich diese gepatchte cp-Version bestimmt schon seit 1-2 Jahren benutze, bin ich auch nicht sofort darauf gekommen, dass diese Version Probleme verursachen könnte. Scheinbar wurde mkinitcpio an der betreffenden Stelle auch erst vor kurzem geändert. Laut dem Log von pacman hat erst die aktuelle Version die -t Option verwendet - alle vorherigen Versionen, die ich installiert hatte sind ohne Fehlermeldung durchgelaufen.

In dem Fall werde ich mich nun wohl nach einer Alternativen Version von cp umschauen müssen.

Vielen Dank für deine Hilfe GerBra, das war ein echt dummer Fehler, den ich vermutlich vermeiden hätte können wenn ich besser auf die Ausgabe von Pacman geschaut hätte und den -t Parameter selbst ausprobiert hätte.

GerBra

Und du hast das jeweilige cp aus coreutils auch nach Updates für coreutils immer wieder überschrieben? (/bin/cp)

mkinitcpio hat die Änderung bzgl. cp -t soweit ich im GIT-Log/Diff gesehen habe seit 0.8.4. Seit wann cp nun -t "versteht" weiß ich nicht...
Ich würde solche Sachen ja anders machen, z.B.:
a) die gepatchte Version nach /usr/local/bin
b) User, die dieses gepatchte cp nutzen sollen haben im $PATH /usr/local/bin vor /bin stehen (which cp zeigt dann welches genommen würde). Der Root-User behält seinen normalen PATH (also ohne /usr/local) und schon gäbe es dieses Problem nicht...
oder
c) Einen Alias in der Shell setzten für cp=/usr/local/bin/cp
oder
d) Einen Alias mit anderem bezeichner cpP=/usr/local/bin/cp z.B. und statt cp dann cpP verwenden wenn die progress bar verwendet werden soll.

Ich meine coreutils heißen ja nicht umsonst coreutils ;-) Diese sollten schon original, ungepatcht sein...

Antoras

> c) Einen Alias in der Shell setzten für cp=/usr/local/bin/cp
So habe ich es jetzt auch gemacht. Davor hatte ich nach einem Update cp immer wieder überschrieben.

Ich weiß, eigentlich sollte ich mir mal ein gutes Buch zu Linux her tun, damit ich mal einen Überblick darüber bekomme wie man richtig mit seinem System arbeiten kann. Allerdings treten die "größeren" Probleme nur vllt. jedes halbe Jahr mal auf, weshalb die Hemmschwelle zu hoch ist sich da fortzubilden. Dazu kommt dann noch, dass mir auch die Zeit fehlt, um mich näher mit dem Thema beschäftigen zu können.

4on6

Hallo,
ich habe so ziemlich exakt das gleiche Problem wie in diesem thread beschrieben, und habe auch schon auf archlinux.org mein glück versucht (https://bbs.archlinux.org/viewtopic.php?id=139186).

Beim Starten von einer Live-CD bekomme ich übrigens auch eine Fehlermeldung beim Booten: "Waiting 30 seconds for device /dev/disk/by-label/ARCH_201108 ..."
Nach der Eingabe von "udevadm trigger" kann allerdings normal weitergebootet werden. Nur falls es da vllt. irgendeinen Zusammenhang geben könnte.

bei mir sieht das so aus, "udevadm trigger" bewirkt nichts:

"Waiting 30 seconds for device /dev/disk/by-label/None..."
boot device didn't show up after 30 seconds...
Falling back to interactive prompt
sh: can't access tty: job control turned off
[ramfs /]#

Leider ist mein dvd-laufwerk defekt, so dass ich von usb stick booten muß. Ich bin mir da auch nicht so ganz sicher, ob dieses booten vollständig gelingt (siehe oben), denn dieses Lösungsrezept (http://tinyurl.com/7jor2q9) setzt zB voraus dass der Ordner mnt/ vorhanden ist, ist er bei mir aber nicht.

Die Lösung in diesem thread hilft mir irgendwie auch nicht wirklich - ich habe kein gepatchtes cp (zumindestens weiß ich da nichts von). Ich weiß also nicht wirklich, was ich jetzt machen soll um meinen computer wieder zum booten zu kriegen.

Jeder Tip wäre hochgradig willkommen.