Hallo Liste,
ich fühle mich wie manchen Freitagnachmittag - kurz ich wird gleich wahnsinnig
Gegeben ist ein Intelboard mit USB und FireWire, na beiden Schnittstellentypen stecken je eine externe Festplatte. Intern am SATA gibt es drei Festplatten. Das Betriebssystem (debian) hat nur eine Partition /dev/sda2, kein gesondertes /boot usw. Bootloader ist der grub 1,98 (also 2?) unter debian squeeze.
Steckt beim Anschalten die USB-Platte am Rechner, lädt das grub-Menü, ich kann in dessen "shell" verifizieren, dass die richtige Platte "vorn" ist und wenn ich den Kern starte erhalte ich ne Kernelpanic:
... kernel panic - not syncing: vfs: unable to mount root fs on unknown-block(0,0) ...
Ohne USB-Platte alles kein Problem.
Die Idee: grub könnte die Platten ja anders sortiert sehen, als der zu startende Kern. Also habe ich mich für UUID entschieden. Das ging genau einmal und ich kann nicht sagen in welcher Konstellation, sagen wir also, das geht gar nicht.
Nun möchte ich aber unbedingt trotz der USB-Platte das System starten können ohne manuell das USB-Kabel zu ziehen und nach dem booten wieder zu stecken. Die Vorgeschichte ist hier viel länger und begann mit BIOS-Optionen und lilo, der weder disklabel noch uuid versteht - jetzt ist der Fall aber klarer, der Bootloader lädt immer, ob mit oder ohne USB-Platte, der Kern stört sich aber dran. Was kann ich nun noch machen/probieren? Warum geht UUID aus dem grub nicht, in der fstab steht es doch auch schon?
Mit freundlichen Grüßen / Kind regards Ronny Seffner
Hallo Ronny,
On Thu, Jan 12, 2012 at 19:00:11 +0100, Ronny Seffner wrote:
Gegeben ist ein Intelboard mit USB und FireWire, na beiden Schnittstellentypen stecken je eine externe Festplatte. Intern am SATA gibt es drei Festplatten. Das Betriebssystem (debian) hat nur eine Partition /dev/sda2, kein gesondertes /boot usw. Bootloader ist der grub 1,98 (also 2?) unter debian squeeze.
Und das Rootfilesystem ist auf einer der internen SATA-Platten?
Steckt beim Anschalten die USB-Platte am Rechner, lädt das grub-Menü, ich kann in dessen "shell" verifizieren, dass die richtige Platte "vorn" ist und wenn ich den Kern starte erhalte ich ne Kernelpanic:
... kernel panic - not syncing: vfs: unable to mount root fs on unknown-block(0,0) ...
Ohne USB-Platte alles kein Problem.
Eigentlich sollte Dich das initramfs in eine busybox-Shell schicken, wenn es das Rootfilesystem nicht findet. Hast Du einen eigenen Kernel ohne initramfs gebaut?
BTW, haben die extern ansteckenden Platten auch jeweils einen Bootloader installiert?
Die Idee: grub könnte die Platten ja anders sortiert sehen, als der zu startende Kern. Also habe ich mich für UUID entschieden. Das ging genau einmal und ich kann nicht sagen in welcher Konstellation, sagen wir also, das geht gar nicht.
Mich wundert, dass Squeeze das UUID-basierte mounten bei Dir nicht eh per Default benutzt hat. Bei mir tut es das.
Wie sah es aus, wenn das Rootfilesystem mit der UUID-Methode nicht gefunden wurde? Auch Kernel Panic?
Nun möchte ich aber unbedingt trotz der USB-Platte das System starten können ohne manuell das USB-Kabel zu ziehen und nach dem booten wieder zu stecken.
Man koennte Einfluss auf die Erstellung des initramfs nehmen und die Module fuer USB-Storage und Firewire-Storage dort blacklisten.
Warum geht UUID aus dem grub nicht, in der fstab steht es doch auch schon?
Die fstab ist im initramfs noch gar nicht zugreifbar. Das initramfs soll ja erst das Rootfilesystem finden und mounten, bevor es dann mit dem eigentlichen init-Prozess weitergeht. Das initramfs kann sich nur an die Kernel Commandline halten und die dort uebergebene UUID auf allen Blockdevices suchen. Warum das bei Dir im Fehlerfall mit einer Kernel Panic endet, ist mir unklar. Der Fallback ist wie gesagt eigentlich eine Emergency Shell.
Gruss, Chris
Am 12.01.2012 19:00, schrieb Ronny Seffner:
Hallo Liste,
ich fühle mich wie manchen Freitagnachmittag - kurz ich wird gleich wahnsinnig
hast ja noch einen Tag Zeit dafür ;)
Steckt beim Anschalten die USB-Platte am Rechner, lädt das grub-Menü, ich kann in dessen "shell" verifizieren, dass die richtige Platte "vorn" ist und wenn ich den Kern starte erhalte ich ne Kernelpanic:
... kernel panic - not syncing: vfs: unable to mount root fs on unknown-block(0,0) ...
Ohne USB-Platte alles kein Problem.
Das Problem hatte ich ähnlich bei einer Installation auf einem USB-Stick, grub startet und stirbt danach genauso ab, sobald interne Platten hinzugekommen sind, obwohl im BIOS die Reihenfolge passend eingestellt und der Stick als einziges Bootmedium aktiviert wurde. Die Installation auf dem Stick erfolgte ohne interne Platten. Es scheint so, als ob die Reihenfolge danach (wenn die Controllertreiber geladen werden?) getauscht wird.
Die Idee: grub könnte die Platten ja anders sortiert sehen, als der zu startende Kern. Also habe ich mich für UUID entschieden. Das ging genau einmal und ich kann nicht sagen in welcher Konstellation, sagen wir also, das geht gar nicht.
UUIDs waren bei mir schon standardmäßig aktiv, auch device.map besagte nichts Abweichendes. Eine Lösung hab ich bisher auch noch nicht gefunden, war aber auch nicht so dringend.
Gruß Rico
jonny Seffner ronny@seffner.de (Do 12 Jan 2012 19:00:11 CET):
Hallo Liste,
ich fühle mich wie manchen Freitagnachmittag - kurz ich wird gleich wahnsinnig
Gegeben ist ein Intelboard mit USB und FireWire, na beiden Schnittstellentypen stecken je eine externe Festplatte. Intern am SATA gibt es drei Festplatten. Das Betriebssystem (debian) hat nur eine Partition /dev/sda2, kein gesondertes /boot usw. Bootloader ist der grub 1,98 (also 2?) unter debian squeeze.
Steckt beim Anschalten die USB-Platte am Rechner, lädt das grub-Menü, ich kann in dessen "shell" verifizieren, dass die richtige Platte "vorn" ist und wenn ich den Kern starte erhalte ich ne Kernelpanic:
... kernel panic - not syncing: vfs: unable to mount root fs on unknown-block(0,0) ...
Wie sieht die grub.cfg aus. Bist Du sicher, daß genau die genommen wird vom Grub?
Guten Morgen,
Wie sieht die grub.cfg aus. Bist Du sicher, daß genau die genommen wird vom Grub?
Ich schränke mich mal auf einen Eintrag ein, genügt das?
menuentry 'Debian GNU/Linux, with Linux 3.1.6' --class debian --class gnu-linux --class gnu --class os { insmod part_msdos insmod ext2 set root='(hd0,msdos2)' search --no-floppy --fs-uuid --set c9d2cdd1-d4c7-48f3-a381-2cd26977983a echo 'Loading Linux 3.1.6 ...' linux /boot/vmlinuz-3.1.6 root=/dev/sda2 ro quiet }
Sicher bin ich mir, da man im Bootloader mit "e" in den edit-Modus gelangt, wo der Eintrag genauso aussieht.
Ah, und woher kennt der Kernel das rootfs? Von seiner commandline, oder? Und ich glaube, dort kannst Du nur device-Namen, keine UUIDs oder ähnliches angeben. Jedenfalls nicht, wenn Du keine initrd hast, die diese in Gerätenamen umsetzt und dann das Device mounted.
Korrekt, im Bootloader steht als Parameter "root=UUID=xxx". Ihr meint also, der UUID und LABEL support kann nur mit initramfs funktionieren, da diese Code enthält, die UUID oder LABEL in /dev/irgendwas übersetzt, womit der Ken umgenehn kann. Wahrscheinlich stimmt das sogar, denn ein Distributionskern mit initrd hat auf dem betroffenen System kein Problem per UUID zu booten.
Ich kann also bei einem monolitischen Kernel (also ohne Modulsupport und ohne initrd) kein UUID oder LABEL verwenden. Ferner scheint also der USB-Treiber vor dem für SATA im Kern aufgerufen zu werden und somit könnte man mutmaßen, dass die USB-Platte /dev/sda wird und SATA nach hinten rutscht.
Die Frage ist nun kann man in meiner Art Kern den USB-Stack zeitlich hinter den SATA-Stack legen?
Wie sah es aus, wenn das Rootfilesystem mit der UUID-Methode nicht gefunden wurde? Auch Kernel Panic?
Ja. Egal ob UUID oder normales /dev/sda2 gibts das gleiche Verhalten.
Und Du bist sicher, daß er schon Treiber geladen hat? Auf der Konsole ist zu sehen, daß die Partitionen gefunden wurden?
Ich kann hier jetzt nicht folgen. Wer hat Treiber geladen, der Bootloader offenbar, denn er findet ja den Kern zum Starten. Der Kern wohl auch, weil es keine Module oder initrd gibt und ohne USB-Device bootet dieser ja anstandslos. Von welcher Konsole redest Du jetzt, zu welchem Zeitpunkt?
Wenn Du eh einen eigenen Kernel baust, dann kannst Du dafuer sorgen, dass der Support fuer USB-Storage und Firewire-Storage nicht fest im Kernel-Image drin ist.
Könnte, das will ich aber gar nicht. Keine Module, keine initrd.
Warum baust Du ueberhaupt einen eigenen Kernel?
Das sollte ich mir wohl mal frisch beantworten ... Ich mag keine Module, da die ja theoretisch nachträgliche Manipulation des Kernels ermöglichen. Ich will nur das, was ich wirklich benötige, nicht mehr, da ich mir so Fehlerpotential reduziert erwarte.
Offenbar gibt es noch eine UUID-ohne-initrd Lösung, hat die schon mal wer exerziert? http://www.linux-archive.org/gentoo-user/481167-mounting-root-partition-uuid...
Mit freundlichen Grüßen / Kind regards Ronny Seffner
Hallo Ronny,
On Fri, Jan 13, 2012 at 10:32:23 +0100, Ronny Seffner wrote:
Ich kann also bei einem monolitischen Kernel (also ohne Modulsupport und ohne initrd) kein UUID oder LABEL verwenden.
Wenn der Kernel selbst UUID-basiert mounten soll, kann er das nur fuer Partition-UUIDs, nicht fuer Filesystem-UUIDs. Den passenden Artikel dazu hast Du ja schon selbst gefunden:
http://www.linux-archive.org/gentoo-user/481167-mounting-root-partition-uuid...
Scheint aber nur mit GPT zu funktionieren. Normale DOS-style Partitionstabellen haben keine UUIDs.
Ferner scheint also der USB-Treiber vor dem für SATA im Kern aufgerufen zu werden und somit könnte man mutmaßen, dass die USB-Platte /dev/sda wird und SATA nach hinten rutscht.
Hoechstwahrscheinlich. Seit Kernel 2.6.37 oder so wurde die Settling Time fuer USB-Storage drastisch verkuerzt.
Warum baust Du ueberhaupt einen eigenen Kernel?
Das sollte ich mir wohl mal frisch beantworten ... Ich mag keine Module, da die ja theoretisch nachträgliche Manipulation des Kernels ermöglichen. Ich will nur das, was ich wirklich benötige, nicht mehr, da ich mir so Fehlerpotential reduziert erwarte.
Das kannst Du auch mit Modulen haben. Nachdem beim Booten alle benoetigten Module geladen sind, kannst Du das hier eingeben bzw. von einem Initskript erledigen lassen:
echo 1 > /proc/sys/kernel/modules_disabled
Uebrigens, auch ohne Module laesst sich via /dev/mem Code in den Kernel einbringen. Keine Module zu haben bringt nicht wirklich mehr Sicherheit.
Gruss, Chris
Hallo,
Wenn der Kernel selbst UUID-basiert mounten soll, kann er das nur fuer Partition-UUIDs, nicht fuer Filesystem-UUIDs. Den passenden Artikel dazu hast Du ja schon selbst gefunden:
... und auch gleich mal in einer VM nachgebaut. Ich habe mehrfach geprüft es "richtig" gemacht zu haben - mein Kern mag offenbar keine PARTITIONUUID. Ich werde also verstärkt über Modulsupport nachdenken ;-)
Danke an alle.
Mit freundlichen Grüßen / Kind regards Ronny Seffner
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hallo Ronny,
Am 12.01.2012 19:00, schrieb Ronny Seffner:
/dev/sda2, kein gesondertes /boot usw. Bootloader ist der grub 1,98 (also
Diese
... kernel panic - not syncing: vfs: unable to mount root fs on unknown-block(0,0) ...
und diese Aussage passen nicht zusammen...
Klingt für mich, als ob der Kernel versucht auf die falsche Partition zu zu greifen.
Ich würde eine /boot/grub/grub.conf mit irgendwas wie: [...] menuentry "Ubuntu, Linux 2.6.31-11-generic" {
recordfail=1
save_env recordfail
set quiet=1
insmod ext2
set root=(hd0,1)
search --no-floppy --fs-uuid --set aaaaeaaa-bbbb-cccc-dddd-eeeeeeeeeeee
linux<->/boot/vmlinuz-2.6.31-11-generic root=UUID=aaaaeaaa-bbbb-cccc-dddd-eeeeeeeeeeee ro nmi_watchdog=0 quiet splash initrd<>/boot/initrd.img-2.6.31-11-generic [/...]
versuchen und schauen, was im gebootetem grub beim bearbeiten des Eintrages letztendlich drin steht.
- -- Mit freundlichen Grüßen / With kind regards
Jan Leonhardt
IT-Dienstleistungen IT-Konsultant Administration Softwareentwicklung
lug-dd@mailman.schlittermann.de
-
Christian Perle -
Heiko Schlittermann -
Jan Leonhardt -
Rico Koerner -
Ronny Seffner