[Gelöst] Merkwürdiges Boot-Verhalten

[pferdefreund]

Ich hab da mal eine Frage. Ich habe auf meinem Rechner 2x Debian - einmal produktiv und einmal als Testsystem (Kopie).
Nun habe ich mich mal in der Konfiguration von Lilo vertan.
Mitgegeben wurde root=/dev/hdb3 und in der fstab des Systems war aber fälschlicheweise
/dev/hda1 / ... eingetragen. War ja nicht weiter schlimm - System lief ja ordentlich hoch - was mich aber wundert,
obwohl unter mount und cat /etc/mtab / als /dev/hda1 anzeigt wurde, wurde in Wirklichkeit tatsächlich
/dev/hdb3 als Root-Dateisystem verwendet (Gott sei dank). Erkennbar war das eindeutig an den Datumsangaben unter
/var/log/syslog und anderen Dateien, wie z. B E-Mail-Ordner.
Kann es sein, daß für das Root-Dateisystem die /etc/fstab wurscht ist und nur der Boot-Parameter root=/dev/hdb3
wirklich zählt ? Im Einsatz ist ein Kernel 3.2 - irgendwas - kann leider momentan nicht nachschauen, weil auf Maloche.
Zum Einsatz als Boot-Manager kommt übrigens Lilo - der ist mir persönlich einfacher zu handhaben wie Grub und Grub2 - aber
das ist ja Geschmackssache..

[Natureshadow]

Hallo,

es gibt ein virtuelles Dateisystem namens rootfs, das aus diesem Kernelparameter abgeleitet wird.

Ausschlaggebend ist nicht /etc/mtab (und die daraus abgeleitete Ausgabe von mount) sondern /proc/mounts.

-nik

[Livingston]

Du solltest dem Braten auf keinen Fall trauen.
Die Booloader (Lilo, Grub0.97, Grub 2 ,...) laden den Kernel von der Bootpartiton, die bei deren Einrichtung/Update konfiguriert wurde.
Auch die root-Partition wird entsprechend dieser Partion erstmal eingebunden.
Zum Zeitpunkt des Bootens dem Loader sind weder fstab noch mtab bekannt.
Es werden daher die Startscripte der root-Partition gestartet, die der Bootloader kennt. Eines dieser Scripte mountet dann die Partitionen, wie sie in der dort vorgefundenen fstab vorliegen.Möglicherweise wird dein Test-root-Verzeichnis gar nicht eingebunden, da bereits ein anderes beim Booten gemountet wurde.
Zu beachten ist auch, dass die richtige initrd/initramfs-Datei geladen wird. Auch diese könnte falsche Annahmen bzgl. der einzubindenden Partion machen.

Also, auch wenn's zufällig läuft: Das Ganze könnte ziemlich fix inkosistent werden, z.B. bei einem Upgrade. Deshalb solltest Du die Bootkonfiguration auf jeden Fall korrekt einstellen und auch eine neue initrd für Dein Testsystem kreieren.

Bis die Nächte,
Livi

[pferdefreund]

Die Bootkonfiguration wurde selbstverständlich korrigiert.
Initramfs oder initrd brauch ich nicht, da ich mir generell Kernel baue, die alles "an Bord" haben, was zum Systemstart notwendig ist - genau um solche Fehler auszuschließen.
Das mit dem /proc/mounts werde ich mir für die Zukunft merken - man lernt halt nie aus...
Ich hab mir schon fast gedacht, daß die Ausgabe von mount bez cat /etc/mtab nicht wirklich stimmt.
Danke für die Hinweise - da kann ich ja wieder beruhigt auf die Koppel - da waren noch ein paar junge Stuten...wieher...

[pferdefreund]

Hab da jetzt mal nachgeschaut - wie erkenne ich denn, wer /dev/root ist - die anderen sind ja klar (cat /proc/mounts)
Ist halt nur so die Neugier...

/dev/root / ext3 rw,noatime,errors=remount-ro,barrier=1,data=writeback 0 0
tmpfs /lib/init/rw tmpfs rw,nosuid,relatime,mode=755 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev tmpfs rw,relatime,size=10240k,mode=755 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev,relatime 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620 0 0
fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0
/dev/hdb1 /disk2 ext3 rw,noatime,errors=remount-ro,barrier=1,data=writeback 0 0
/dev/hdd1 /ddvdb ext2 rw,noatime,errors=continue 0 0

[Natureshadow]

wie erkenne ich denn, wer /dev/root ist

Code: Alles auswählen

# readlink /dev/root

[cosmac]

hi,

wenn's doch nur so einfach wäre; es gibt kein /dev/root
es gibt ein paar andere Infos, hier (syslinux, keine initrd) sieht's z.B. so aus:

Code: Alles auswählen

$ cat /proc/mounts
rootfs / rootfs rw 0 0
/dev/root / ext4 rw,relatime,errors=remount-ro,user_xattr,acl,barrier=1,data=ordered 0 0
devtmpfs /dev devtmpfs rw,relatime,size=451532k,nr_inodes=112883,mode=755 0 0
(...)
$ cat /proc/self/mountinfo
12 1 8:2 / / rw,relatime - ext4 /dev/root rw,errors=remount-ro,user_xattr,acl,barrier=1,data=ordered
13 12 0:5 / /dev rw,relatime - devtmpfs devtmpfs rw,size=451532k,nr_inodes=112883,mode=755
(...)
$ cat /proc/cmdline
ro panic=42 root=/dev/sda2 quiet fbcon=font:SUN12x22 2 BOOT_IMAGE=v31-0.ag1 
$ dmesg | grep root
[    3.462651] VFS: Mounted root (ext4 filesystem) readonly on device 8:2.

wirklich überzeugend finde ich das allerdings nicht. Man sollte meinen, dass der Kernel genau das "root=/dev/xxx" aus der cmdline benutzt oder garnicht startet. Aber wenn ich die grub2-Horrorgeschichten so lese, bin ich da auch nicht mehr sicher...

[Natureshadow]

Wieso gibt es bei dir kein /dev/root ?

Welche Kernel-Version benutzt du da? Und benutzt du udev?

Bei mir tut das so:

Code: Alles auswählen

nik@keks:~ $ readlink /dev/root
dm-1

[pferdefreund]

readlink ist für mich die Lösung - das fruchtet.

pferd@arbeitspferd:~$ readlink /dev/root
hda1
pferd@arbeitspferd:~$

[Livingston]

Aus der Kernel-Doku <kernel source path>/Documentation/devices.txt:

4 block Aliases for dynamically allocated major devices to be used
when its not possible to create the real device nodes
because the root filesystem is mounted read-only.

0 = /dev/root

Dieses Gerät wird vom Kernel beim Booten gemountet, d.h. bevor die fstab verarbeitet wird.
Bin da auch mal in meinen initrd-Eigenbauexperimenten drüber gestolpert und habe ein paar Stunden meines Lebens damit verschwendet, hinter das Geheimnis dieses Gerätes zu kommen.
Sobald das Wurzelverzeichnis gemountet und fstab verarbeitet ist, wird /dev/root nicht mehr gebraucht. initrd bzw. initramfs oder auch spätere Boot-Scripte können je nach Distribution/Version dieses ominöse Gerät löschen. Es ist neuerdings üblich, /dev/root als Fallback stehen zu lassen. Das kann beim Herumexperimentieren ganz nützlich sein.

[Clio]

pferd@arbeitspferd:~$

Ist jetzt zwar sehr OT, aber ich wollte nur mal sagen, daß mir @pferdefreunds Systemname ausnehmend gut gefällt...