AW: boot Probleme
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 -- Ronny Seffner | Alter Viehweg 1 | 01665 Triebischtal www.seffner.de | ro...@seffner.de | +49 35245 72950 ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
AW: boot Probleme
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-no-initrd-needed.html
Mit freundlichen Grüßen / Kind regards
Ronny Seffner
--
Ronny Seffner | Alter Viehweg 1 | 01665 Triebischtal
www.seffner.de | ro...@seffner.de | +49 35245 72950
___
Lug-dd maillist - Lug-dd@mailman.schlittermann.de
https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: boot Probleme
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-no-initrd-needed.html 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 -- Christian Perlechris AT linuxinfotag.de 010111 http://chris.silmor.de/ 101010 LinuxGuitarKitesBicyclesBeerPizzaRaytracing ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
boot Probleme
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 -- Ronny Seffner | Alter Viehweg 1 | 01665 Triebischtal www.seffner.de | ro...@seffner.de | +49 35245 72950 ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: boot Probleme
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 -- Christian Perlechris AT linuxinfotag.de 010111 http://chris.silmor.de/ 101010 LinuxGuitarKitesBicyclesBeerPizzaRaytracing ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: boot Probleme
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 smime.p7s Description: S/MIME Kryptografische Unterschrift ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: boot Probleme
jonny Seffner ro...@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? -- Heiko signature.asc Description: Digital signature ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: boot Probleme
Und das Rootfilesystem ist auf einer der internen SATA-Platten? Ja. Eigentlich sollte Dich das initramfs in eine busybox-Shell schicken, wenn es das Rootfilesystem nicht findet. Hast Du einen eigenen Kernel ohne initramfs gebaut? Genau, eigener Kern ohne initramfs. BTW, haben die extern ansteckenden Platten auch jeweils einen Bootloader installiert? Nein, haben sie nicht. Aber das würde doch nicht helfen? Mich wundert, dass Squeeze das UUID-basierte mounten bei Dir nicht eh per Default benutzt hat. Bei mir tut es das Geht mangels initrd nicht wenn man sich /etc/grub.d/10_linux ansieht. 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. Ronny ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: boot Probleme
-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 eaaa----
linux-/boot/vmlinuz-2.6.31-11-generic
root=UUID=eaaa---- 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
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk8PR3AACgkQNK8mtpBqE+a9/gCfZEyO/k4tmayBwP0ffrEl0CIF
9BIAoLAauRCQOIuYc29UN4NM8tSDDrEG
=3E2F
-END PGP SIGNATURE-
___
Lug-dd maillist - Lug-dd@mailman.schlittermann.de
https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: boot Probleme
Hi Ronny, On Thu, Jan 12, 2012 at 21:47:09 +0100, Ronny Seffner wrote: Und das Rootfilesystem ist auf einer der internen SATA-Platten? Ja. Okay. Eigentlich sollte Dich das initramfs in eine busybox-Shell schicken, wenn es das Rootfilesystem nicht findet. Hast Du einen eigenen Kernel ohne initramfs gebaut? Genau, eigener Kern ohne initramfs. 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. BTW, haben die extern ansteckenden Platten auch jeweils einen Bootloader installiert? Nein, haben sie nicht. Aber das würde doch nicht helfen? Nein, es wuerde eher stoeren. Mich wundert, dass Squeeze das UUID-basierte mounten bei Dir nicht eh per Default benutzt hat. Bei mir tut es das Geht mangels initrd nicht wenn man sich /etc/grub.d/10_linux ansieht. Warum baust Du ueberhaupt einen eigenen Kernel? Gruss, Chris -- Christian Perlechris AT linuxinfotag.de 010111 http://chris.silmor.de/ 101010 LinuxGuitarKitesBicyclesBeerPizzaRaytracing ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: boot Probleme
Ronny Seffner ro...@seffner.de (Do 12 Jan 2012 21:47:09 CET): Und das Rootfilesystem ist auf einer der internen SATA-Platten? Ja. Eigentlich sollte Dich das initramfs in eine busybox-Shell schicken, wenn es das Rootfilesystem nicht findet. Hast Du einen eigenen Kernel ohne initramfs gebaut? Genau, eigener Kern ohne initramfs. 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. 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? -- Heiko signature.asc Description: Digital signature ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
