warning: can't open /etc/mtab: no such file or directory
hallo beim Programmstart wird an der nachstehend (anhand von dmesg) beschriebenen Stelle die Warnung ausgegeben: "warning: can't open /etc/mtab: no such file or directory" (Die Meldung ist danach in keinem Protokoll mehr auffindbar.) Beim googlen habe ich gelesen, dass das was mit "mount" zu tun hat, konnte jedoch nirgends eine definitive Hilfe zum Abstellen des Fehlers finden. Deshalb habe ich hier zusätzlich meine "/proc/mounts" und "/etc/mtab" aufgeführt: - - - d m e s g: - - - - [ . . . ] ACPI: (supports S0 S1 S4bios S5) RAMDISK: Compressed image found at block 0 VFS: Mounted root (ext2 filesystem). SCSI subsystem initialized scsi0 : AdvanSys SCSI 3.3GJ: PCI Ultra: IO 0xDC00-0xDC0F, IRQ 0x5 - - - - - - - - warning: Can't open /etc/mtab: No such file or directory warning: Can't open /etc/mtab: No such file or directory - - - - - - - - VFS: Mounted root (ext2 filesystem) readonly. Trying to move old root to /initrd ... failed Unmounting old root [ . . . . ] - - - - - - - - - - - - /proc/mounts rootfs / rootfs rw 0 0 /dev/root / ext2 rw 0 0 proc /proc proc rw 0 0 sysfs /sys sysfs rw 0 0 devpts /dev/pts devpts rw 0 0 tmpfs /dev/shm tmpfs rw 0 0 /dev/dvd /media/dvd subfs ro,nosuid,nodev 0 0 usbfs /proc/bus/usb usbfs rw 0 0 - - - - - - - - - - - - - /etc/mtab /dev/hda2 / ext2 rw,acl,user_xattr 0 0 proc /proc proc rw 0 0 tmpfs /dev/shm tmpfs rw 0 0 devpts /dev/pts devpts rw,mode=0620,gid=5 0 0 /dev/hdc /media/dvd subfs \ ro,nosuid,nodev,fs=cdfss,procuid,iocharset=utf8 0 0 usbfs /proc/bus/usb usbfs rw 0 0 - - - - - - - - - - Kann mir vielleicht jemand sagen, was geändert oder eingetragen werden muss, damit die Meldung entfällt? Ist es überhaupt richtig, dass der Inhalt der beiden Dateien unterschiedlich ist? Für jede Hilfe im voraus besten Dank Gruß Rolf
* Rolf Hoff schrieb:
beim Programmstart wird an der nachstehend (anhand von dmesg) beschriebenen Stelle die Warnung ausgegeben: [...] SCSI subsystem initialized scsi0 : AdvanSys SCSI 3.3GJ: PCI Ultra: IO 0xDC00-0xDC0F, IRQ 0x5 [...] "warning: can't open /etc/mtab: no such file or directory"
[...]
VFS: Mounted root (ext2 filesystem) readonly.
da ist einiges kaputt ... Du hast noch nicht die /etc/fstab gemailt und hier berichtet, ob Dein System überhaupt schonmal startete. Es sieht so aus, also ob Dein SCSI-Controller nach der Installation und dann dem ersten Booten von Festplatte gar nicht erkannt wurde bzw in der initrd nicht das richtige Modul drinnensteht. Ekkard
Ekkard Gerlach schrieb:
* Rolf Hoff schrieb:
beim Programmstart wird an der nachstehend (anhand von dmesg) beschriebenen Stelle die Warnung ausgegeben: [...] SCSI subsystem initialized scsi0 : AdvanSys SCSI 3.3GJ: PCI Ultra: IO 0xDC00-0xDC0F, IRQ 0x5 [...] "warning: can't open /etc/mtab: no such file or directory"
[...]
VFS: Mounted root (ext2 filesystem) readonly.
da ist einiges kaputt ...
Was meinst Du damit? Sieh Dir meinen dmsg-Text einige Zeilen höher an.
Du hast noch nicht die /etc/fstab gemailt und hier
hänge ich heute hier an.
berichtet, ob Dein System überhaupt schonmal startete.
Seit Jahren ohne Probleme, halt nur mit der genannten Warnung.
Es sieht so aus, also ob Dein SCSI-Controller nach der Installation und dann dem ersten Booten von Festplatte gar nicht erkannt wurde bzw in der initrd nicht das richtige Modul drinnensteht.
Neee, SCSI wird gebootet, aber weil die Geräte nicht eingeschaltet sind, werden sie im Protokoll nicht genannt. In der initred steht auch das richtige Modul drin.
Ekkard
hallo Ekkard, es freut mich wirklich, dass Du Dich meiner Probleme annehmen willst. Aber mit allem, was Du oben sagst, bist du völlig auf dem Holzweg ;-) Wahrscheinlich macht VFS bei root nur etwas falsch, weil es ihm in vmlinuz so gesagt wird. Mal angenommen, das ist es wirklich, wo bzw. "wie" ändert man das dann? Es kann ja auch sein, dass "linuxrc" dabei mitwirkt. Aber m.E. gibt es die doch gar nicht mehr. Wie gehts jetzt von initrd zu RAMdisk und weiter? Dazwichen muss irgendwo der Aufruf für VFS stecken. Wenn auch ich auf dem Holzweg bin, dann stellt sich weiter die Frage, was ist das, was da die Warnung auslöst. Hier noch meine /etc/fstab: /dev/hda2 / ext2 acl,user_xattr 1 1 /dev/hda1 swap swap pri=42 0 0 devpts /dev/pts devpts mode=0620,gid=5 0 0 proc /proc proc defaults 0 0 usbfs /proc/bus/usb usbfs noauto 0 0 sysfs /sys sysfs noauto 0 0 /dev/dvd /media/dvd subfs fs=cdfss,ro,procuid,nosuid,nodev,exec,iocharset=utf8 0 0 /dev/cdrom /media/cdrom auto ro,noauto,user,exec 0 0 /dev/fd0 /media/floppy auto noauto,user,sync 0 0 /dev/cdrecorder /media/cdrecorder auto ro,noauto,user,exec 0 0 Gruß Rolf
Hallo, Am Sat, 25 Sep 2004, Rolf Hoff schrieb:
- - - d m e s g: - - - - [ . . . ] ACPI: (supports S0 S1 S4bios S5) RAMDISK: Compressed image found at block 0 VFS: Mounted root (ext2 filesystem). SCSI subsystem initialized scsi0 : AdvanSys SCSI 3.3GJ: PCI Ultra: IO 0xDC00-0xDC0F, IRQ 0x5 - - - - - - - - warning: Can't open /etc/mtab: No such file or directory warning: Can't open /etc/mtab: No such file or directory - - - - - - - - VFS: Mounted root (ext2 filesystem) readonly. Trying to move old root to /initrd ... failed Unmounting old root [ . . . . ]
Dir fehlt in der initrd die /etc/mtab und/oder es versucht etwas zu frueh (eben bevor / und damit /etc/ gemountet ist) zu (un-)mounten. Aber: es ist eine Warnung und in diesem Falle wohl ignorierbar. -dnh -- I don't see anything wrong with being arrogant and not at all helpful. -- Paul Tomblin
David Haller schrieb:
Hallo,
Am Sat, 25 Sep 2004, Rolf Hoff schrieb:
- - - d m e s g: - - - - [ . . . ] ACPI: (supports S0 S1 S4bios S5) RAMDISK: Compressed image found at block 0 VFS: Mounted root (ext2 filesystem). SCSI subsystem initialized scsi0 : AdvanSys SCSI 3.3GJ: PCI Ultra: IO 0xDC00-0xDC0F, IRQ 0x5 - - - - - - - - warning: Can't open /etc/mtab: No such file or directory warning: Can't open /etc/mtab: No such file or directory - - - - - - - - VFS: Mounted root (ext2 filesystem) readonly. Trying to move old root to /initrd ... failed Unmounting old root [ . . . . ]
Dir fehlt in der initrd die /etc/mtab und/oder es versucht etwas zu frueh (eben bevor / und damit /etc/ gemountet ist) zu (un-)mounten.
Aber: es ist eine Warnung und in diesem Falle wohl ignorierbar.
-dnh
OK, es ist nur eine Warnung, aber trotzdem, wie kriege ich /etc/mtab in die initrd rein? Mit der Appendzeile von lilo? Oder wie sonst? Wie lautet der Text bzw. das Kommando? Danke für die Hilfe vorab Gruß Rolf
Hallo, Am Tue, 28 Sep 2004, Rolf Hoff schrieb:
David Haller schrieb: [..]
Dir fehlt in der initrd die /etc/mtab und/oder es versucht etwas zu frueh (eben bevor / und damit /etc/ gemountet ist) zu (un-)mounten.
Aber: es ist eine Warnung und in diesem Falle wohl ignorierbar. [..] OK, es ist nur eine Warnung, aber trotzdem, wie kriege ich /etc/mtab in die initrd rein? Mit der Appendzeile von lilo? Oder wie sonst? Wie lautet der Text bzw. das Kommando?
Das weiss ich leider auch nicht, da ich keine initrd verwende. Schau aber erstmal, wo genau die Warnung kommt, bzw. maile mal die ~10 Zeilen direkt vor der Meldung. -dnh -- [Virenscanner] Stattdessen gehört auf einen Windows-Arbeitsplatz ein guter, selbstaktualisierender lokaler Scanner, der die Windows-Kiste so richtig schön langsam beim Öffnen von Dateien macht, um den Windows-Anwender zu motivieren, auf Linux umzusteigen. -- Kristian Koehntopp
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 29 September 2004 00:52, David Haller wrote:
OK, es ist nur eine Warnung, aber trotzdem, wie kriege ich /etc/mtab in die initrd rein? Mit der Appendzeile von lilo? Oder wie sonst? Wie lautet der Text bzw. das Kommando?
Das weiss ich leider auch nicht, da ich keine initrd verwende.
Eigentlich gibt es dafür das Shell Script /sbin/mkinitrd. Doch gerade für diesen Zweck dürfte es nicht taugen. Prinzipiell ist ein initrd nur ein mit gzip komprimiertes Filesystem Image. Du kannst also einen bestehenden initrd nehmen und mit zcat erstmal entkomprimieren: zcat /boot/initrd >/tmp/initrd.uncompressed Dieses Image kannst Du dann mounten: mount -o loop /tmp/initrd.uncompressed /mnt Nun siehst Du den Inhalt des Initrd unter /mnt gemountet. Du kannst auch Files dort anlegen: cp /etc/mtab /mnt/etc oder touch /mnt/etc/mtab Wenn Du alles nötige reinkopiert hast, unmountest Du das Ding wieder: umount /mnt und komprimierst es: gzip -9 /boot/initrd.new Jetzt kannst Du den unkomprimierten initrd entsorgen: rm /tmp/initrd.uncompressed Dann solltest Du den neuen initrd noch in Deine Konfiguration einbinden, also /boot/grub/menu.lst editieren, oder probeweise die Kernel Commandline beim Booten direkt eingeben. Falls Du lilo benutzt, ist /etc/lilo.conf zu editieren und lilo auszuführen. Soweit zum Thema initrd. Zu Deinem Problem: On Saturday 25 September 2004 19:24, Rolf Hoff wrote:
"warning: can't open /etc/mtab: no such file or directory"
Das ist wirklich nur eine Warnung. Der Mount Befehl schreibt dieses File bei jedem Mount bzw. Umount, einfach um den Überblick zu behalten, was gemountet ist. Der Kernel liefert Die fast die selbe Information in /proc/mounts. In der Kernel Mailing Liste taucht immer mal wieder eine Diskussion auf, ob /etc/mtab nicht durch einen Symbolic Link auf /proc/mounts ersetzt werden sollte. /etc/mtab enthält aber einige Information mehr (Flags). Das ist seine Existenzberechtigung. Ich bin mir im Moment nicht sicher, ob der Initrd nicht read-only gemountet wird. Wenn das so ist, würde der Einbau der /etc/mtab in den initrd einfach nur eine andere Fehlermeldung erzeugen: Kann /etc/mtab nicht schreiben: read-only filesystem. Ich würde Dir empfehlen diese Warnung einfach zu ignorieren. War diese Warnung Dein eigentliches Problem? Torsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBWnrZwicyCTir8T4RAgMIAJsHNTyx9RmfOCmaP52KbZE/nx48nwCdFsjE dgZYNpJ2CjY25fEv8HxQEJs= =43z5 -----END PGP SIGNATURE-----
Torsten Förtsch schrieb:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wednesday 29 September 2004 00:52, David Haller wrote:
OK, es ist nur eine Warnung, aber trotzdem, wie kriege ich /etc/mtab in die initrd rein? Mit der Appendzeile von lilo? Oder wie sonst? Wie lautet der Text bzw. das Kommando?
Das weiss ich leider auch nicht, da ich keine initrd verwende.
Eigentlich gibt es dafür das Shell Script /sbin/mkinitrd. Doch gerade für diesen Zweck dürfte es nicht taugen. Prinzipiell ist ein initrd nur ein mit gzip komprimiertes Filesystem Image. Du kannst also einen bestehenden initrd nehmen und mit zcat erstmal entkomprimieren:
zcat /boot/initrd >/tmp/initrd.uncompressed
Dieses Image kannst Du dann mounten:
mount -o loop /tmp/initrd.uncompressed /mnt
Nun siehst Du den Inhalt des Initrd unter /mnt gemountet. Du kannst auch Files dort anlegen:
cp /etc/mtab /mnt/etc
oder
touch /mnt/etc/mtab
Wenn Du alles nötige reinkopiert hast, unmountest Du das Ding wieder:
umount /mnt
und komprimierst es:
gzip -9 /boot/initrd.new
Jetzt kannst Du den unkomprimierten initrd entsorgen:
rm /tmp/initrd.uncompressed
Dann solltest Du den neuen initrd noch in Deine Konfiguration einbinden, also /boot/grub/menu.lst editieren, oder probeweise die Kernel Commandline beim Booten direkt eingeben. Falls Du lilo benutzt, ist /etc/lilo.conf zu editieren und lilo auszuführen.
Soweit zum Thema initrd. Zu Deinem Problem:
On Saturday 25 September 2004 19:24, Rolf Hoff wrote:
"warning: can't open /etc/mtab: no such file or directory"
Das ist wirklich nur eine Warnung. Der Mount Befehl schreibt dieses File bei jedem Mount bzw. Umount, einfach um den Überblick zu behalten, was gemountet ist. Der Kernel liefert Die fast die selbe Information in /proc/mounts. In der Kernel Mailing Liste taucht immer mal wieder eine Diskussion auf, ob /etc/mtab nicht durch einen Symbolic Link auf /proc/mounts ersetzt werden sollte. /etc/mtab enthält aber einige Information mehr (Flags). Das ist seine Existenzberechtigung.
Ich bin mir im Moment nicht sicher, ob der Initrd nicht read-only gemountet wird. Wenn das so ist, würde der Einbau der /etc/mtab in den initrd einfach nur eine andere Fehlermeldung erzeugen: Kann /etc/mtab nicht schreiben: read-only filesystem. Ich würde Dir empfehlen diese Warnung einfach zu ignorieren.
War diese Warnung Dein eigentliches Problem?
ja, vielen Dank. Aber nachträglich sind Deine Ausführungen zur initrd für mich auch wertvoll. Nochmals vielen Dank Gruß Rolf
Torsten Förtsch schrieb:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wednesday 29 September 2004 00:52, David Haller wrote:
OK, es ist nur eine Warnung, aber trotzdem, wie kriege ich /etc/mtab in die initrd rein? Mit der Appendzeile von lilo? Oder wie sonst? Wie lautet der Text bzw. das Kommando?
Das weiss ich leider auch nicht, da ich keine initrd verwende.
Eigentlich gibt es dafür das Shell Script /sbin/mkinitrd. Doch gerade für diesen Zweck dürfte es nicht taugen. Prinzipiell ist ein initrd nur ein mit gzip komprimiertes Filesystem Image. Du kannst also einen bestehenden initrd nehmen und mit zcat erstmal entkomprimieren:
zcat /boot/initrd >/tmp/initrd.uncompressed
Dieses Image kannst Du dann mounten:
mount -o loop /tmp/initrd.uncompressed /mnt
Nun siehst Du den Inhalt des Initrd unter /mnt gemountet. Du kannst auch Files dort anlegen:
cp /etc/mtab /mnt/etc
oder
touch /mnt/etc/mtab
Wenn Du alles nötige reinkopiert hast, unmountest Du das Ding wieder:
umount /mnt
und komprimierst es:
gzip -9 /boot/initrd.new
Jetzt kannst Du den unkomprimierten initrd entsorgen:
rm /tmp/initrd.uncompressed
Dann solltest Du den neuen initrd noch in Deine Konfiguration einbinden, also /boot/grub/menu.lst editieren, oder probeweise die Kernel Commandline beim Booten direkt eingeben. Falls Du lilo benutzt, ist /etc/lilo.conf zu editieren und lilo auszuführen.
Soweit zum Thema initrd. Zu Deinem Problem:
hallo Torsten, habe inzwischen mal die initrd uncompressed und nach /mnt gemountet. Da habe ich unter /mnt/etc dann eine fstab gefunden, die aber einen ganz anderen Inhalt aufweist, als die fstab unter /etc/fstab, und zwar: - - - -snipp - - - - sysfs /sys sysfs defaults 0 0 - - - - s n a p p - - - Weiter nichts. Mit welchem Inhalt muss denn dann die /etc/mtab nach /mnt/etc/mtab (in die initrd hinein) kopiert bzw. geschrieben werden? Außerdem habe ich auch festgestellt, dass es unter /mnt/proc/ keine /mnt/proc/mounts (in der initrd) gibt. Wenn es nun keine /proc/mounts in der initrd gibt, warum sollte dann /etc/mtab etwas in der initrd zu suchen haben? Noch bei der Gelegenheit: Bei einem "mkinitrd" nach Thomas Hertweck wie folgt: - - - s n i p p - - - mkinitrd -k /boot/vmlinuz -i /boot/initrd-2.6.5-7.108-1 -s 1024x768 - - - - s n a p p - - - gibt es anschließend keine *.gz, und trotzdem ist die Datei komprimiert. Würde mich freuen, wenn Du diese Fragen auch noch beantworten würdest. Jetzt interessiert mich das alles nun auch noch. Wirklich. Grüße Rolf
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 29 September 2004 22:12, Rolf Hoff wrote:
hallo Torsten, habe inzwischen mal die initrd uncompressed und nach /mnt gemountet. Da habe ich unter /mnt/etc dann eine fstab gefunden, die aber einen ganz anderen Inhalt aufweist, als die fstab unter /etc/fstab, und zwar: - - - -snipp - - - - sysfs /sys sysfs defaults 0 0 - - - - s n a p p - - - Weiter nichts.
Ich denke, Du solltest erstmal den Zweck des initrd verstehen. Also, früher als linux noch so klein war, dass alle gängige und unterstützte Hardware in einen ca. 1MB großen Kernel passte, brauchte man keinen initrd. Es gab einfach zur Installation eine Boot Diskette, die den Kernel enthielt und evtl. noch eine weitere mit einem Mini-System zur Installation. Oft enthielt aber eine Diskette beides. Distributoren wie Suse standen damals vor dem Problem, dass sie zur Installation Kernel liefern mussten, die auf dem Zielsystem wenigstens irgendwie liefen. Sonderkonfigurationen, wie z.B. ein SCSI System, musste man oftmals später per Hand in den Kernel kompilieren. Für einen Linux Anfänger war das keine leichte Aufgabe. Ich kann mich an Suse Versionen mit einer ganzen Menge verschiedener Kernel erinnern, von denen man sich den aussuchte, der am besten zur gegebenen Hardware passte. Außerdem unterstützte Linux immer mehr Hardware, so dass es in vielen Kernels Teile gab, die nie auf dem gegebenen System genutzt wurden, die aber immer Hauptspeicher belegten. Um das Problem zu lösen, wurde der Kernel modularisiert. Einzelne Treiber können jetzt als Modul kompiliert werden und erst, wenn sie benötigt werden, in den Kernel geladen werden. Wenn Du bei einem heutigen Suse Linux im Betrieb mal lsmod eingibst, siehst Du wie weit dieser Prozess fortgeschritten ist. Heute kann sogar der Keyboard- und Maustreiber als Modul kompiliert werden. Nun entsteht aber ein weiteres Problem. Wenn man nämlich einen stark modularisierten Kernel hat, so ist dieser am Anfang relativ hilflos. Oft kann er nicht mal sein Root Filesystem finden und verstehen. Dazu wurde folgende Lösung gefunden. Der Boot Loader lädt den Kernel mit Bios-Hilfe in den Speicher. Wenn der Boot Loader (grub oder lilo) aber den Kernel in den Speicher laden kann, dann kann er ja auch noch ein weiteres File in den Speicher laden. Das ist der initrd. Nun ist der Kernel so kompiliert, dass er eine RAM Disk kennt und das ext2 Filesystem versteht. Selbst, wenn diese beiden Dinge zum eigentlichen Betrieb nie wieder benötigt werden, müssen sie zum Booten im Kernel einkompiliert sein. (Sie benötigen aber zum Glück recht wenig Platz). Damit kennt nun der Kernel einen Standard-Weg, wie er ein bestimmtes Filesystem finden (mounten) kann. Dieses mountet er als Root Filesystem. Das Root Filesystem ist bis jetzt aber nur im Hauptspeicher und der Kernel kennt Deine Platte immer noch nicht. Jetzt kommt ein spezielles Programm namens "/linurc" in der initrd zum Zuge. Der Kernel startet einfach dieses Programm und geht davon aus, dass es den Kernel schon irgendwie so konfiguriert, dass er danach das eigentliche Root Filesystem (auf der Platte) findet. Meist muss linuxrc dafür nicht viel mehr machen, als z.B. den SCSI / IDE Treiber und den Treiber für reiserfs zu laden. Er kann aber auch ein Netzwerk-Interface konfigurieren und das Root Filesystem über nfs mounten. Damit linuxrc (meist ein Shell Script) seine Arbeit tun kann muss der initrd die nötigen Teile mitbringen. Da wären (mindestens): - - wenigstens eine Shell samt nötiger shared libs - - insmod - - die benötigten Module Als letztes schreibt initrd die Device Nummer des eigentlichen Root Filesystems nach /proc/sys/kernel/real-root-dev. Dafür muss aber das proc Filesystem auch gemountet sein. Und hier kommt Dein mount Problem. Linuxrc versucht irgendwann /proc zu mounten und der mount Befehl gibt die Warnung aus. Normalerweise kann man mit der Option -n verhindern, dass mount oder umount /etc/mtab versuchen zu schreiben. Suse hat wohl an einer Stelle in /linuxrc vergessen, diese Option mitzugeben: opi:/home # cat /mnt/linuxrc | grep mount mount -n -tproc proc /proc mount -n -tsysfs sysfs /sys > /dev/null 2>&1 mount -n -ttmpfs tmpfs /dev/shm umount -n /proc umount -n /sys umount /dev/shm <== das ist der Schuldige
Mit welchem Inhalt muss denn dann die /etc/mtab nach /mnt/etc/mtab (in die initrd hinein) kopiert bzw. geschrieben werden?
So, nun denke ich dargelegt zu haben, dass Du gar kein /etc/mtab in Deinem initrd brauchst. Du müsstest einfach den Fehler in linuxrc beheben. Dieser wird allerdings mit /sbin/mkinitrd erzeugt. Dort habe ich bei mir folgendes gefunden: opi:/home # cat -n /sbin/mkinitrd |grep -C5 1337 1332 |done 1333 | 1334 |die() { 1335 | umount -n /proc 1336 | umount -n /sys 1337 | umount /dev/shm <== the culprit 1338 | exit \$1 1339 |} 1340 | 1341 |# Fallback root device number 1342 |rootdevn=$rootdevn In Zeile 1337 fehlt einfach das -n.
Außerdem habe ich auch festgestellt, dass es unter /mnt/proc/ keine /mnt/proc/mounts (in der initrd) gibt.
natürlich. Wenn Dein System normal läuft, ist das proc Filesystem ja als /proc gemountet. Wenn der initrd in Betrieb ist, also in einer der ersten Phasen des Bootens, ist er als Root Filesystem (/) gemountet. Linuxrc mountet dann proc nach /proc (im initrd) und umountet /proc am Ende wieder.
Wenn es nun keine /proc/mounts in der initrd gibt, warum sollte dann /etc/mtab etwas in der initrd zu suchen haben?
siehe oben
Noch bei der Gelegenheit: Bei einem "mkinitrd" nach Thomas Hertweck wie folgt: - - - s n i p p - - - mkinitrd -k /boot/vmlinuz -i /boot/initrd-2.6.5-7.108-1 -s 1024x768 - - - - s n a p p - - - gibt es anschließend keine *.gz, und trotzdem ist die Datei komprimiert.
Linux/Unix gibt nicht sehr viel auf Endungen wie .gz. In der urspünglichen Philosophie steht der Typ eines Files oder des Inhalts irgendwie maschinenlesbar am Anfang des Files. Meist nennt man diesen Marker "magic number". Ganz durchhalten lies sich das nicht. Aber ein nützliches Kommando, wenn Du nicht weißt, was ein File ist, ist "file". Es benutzt den Inhalt des Files: opi:/home # file /boot/initrd /boot/initrd-2.6.8-20040918095208-default /tmp/initrd.uncompressed /mnt/linuxrc /bin/bash /boot/initrd: symbolic link to `initrd-2.6.8-20040918095208-default' /boot/initrd-2.6.8-20040918095208-default: gzip compressed data, was "initrd_small", from Unix, max compression /tmp/initrd.uncompressed: Linux rev 1.0 ext2 filesystem data (mounted or unclean) /mnt/linuxrc: Bourne shell script text /bin/bash: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), stripped
Würde mich freuen, wenn Du diese Fragen auch noch beantworten würdest. Jetzt interessiert mich das alles nun auch noch. Wirklich.
Hat's geholfen? Torsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBXHllwicyCTir8T4RAmjGAJ9rjVjFYu0UqSOFgH5av0PknINlHgCffgAX fqX69m0gR7hrpCmmr/WczqM= =nWki -----END PGP SIGNATURE-----
Torsten Förtsch schrieb:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wednesday 29 September 2004 22:12, Rolf Hoff wrote:
hallo Torsten, habe inzwischen mal die initrd uncompressed und nach /mnt gemountet. Da habe ich unter /mnt/etc dann eine fstab gefunden, die aber einen ganz anderen Inhalt aufweist, als die fstab unter /etc/fstab, und zwar: - - - -snipp - - - - sysfs /sys sysfs defaults 0 0 - - - - s n a p p - - - Weiter nichts.
Ich denke, Du solltest erstmal den Zweck des initrd verstehen. Also, früher als linux noch so klein war, dass alle gängige und unterstützte Hardware in einen ca. 1MB großen Kernel passte, brauchte man keinen initrd. Es gab einfach zur Installation eine Boot Diskette, die den Kernel enthielt und evtl. noch eine weitere mit einem Mini-System zur Installation. Oft enthielt aber eine Diskette beides.
Distributoren wie Suse standen damals vor dem Problem, dass sie zur Installation Kernel liefern mussten, die auf dem Zielsystem wenigstens irgendwie liefen. Sonderkonfigurationen, wie z.B. ein SCSI System, musste man oftmals später per Hand in den Kernel kompilieren. Für einen Linux Anfänger war das keine leichte Aufgabe. Ich kann mich an Suse Versionen mit einer ganzen Menge verschiedener Kernel erinnern, von denen man sich den aussuchte, der am besten zur gegebenen Hardware passte.
Außerdem unterstützte Linux immer mehr Hardware, so dass es in vielen Kernels Teile gab, die nie auf dem gegebenen System genutzt wurden, die aber immer Hauptspeicher belegten.
Um das Problem zu lösen, wurde der Kernel modularisiert. Einzelne Treiber können jetzt als Modul kompiliert werden und erst, wenn sie benötigt werden, in den Kernel geladen werden. Wenn Du bei einem heutigen Suse Linux im Betrieb mal lsmod eingibst, siehst Du wie weit dieser Prozess fortgeschritten ist. Heute kann sogar der Keyboard- und Maustreiber als Modul kompiliert werden.
Nun entsteht aber ein weiteres Problem. Wenn man nämlich einen stark modularisierten Kernel hat, so ist dieser am Anfang relativ hilflos. Oft kann er nicht mal sein Root Filesystem finden und verstehen. Dazu wurde folgende Lösung gefunden. Der Boot Loader lädt den Kernel mit Bios-Hilfe in den Speicher. Wenn der Boot Loader (grub oder lilo) aber den Kernel in den Speicher laden kann, dann kann er ja auch noch ein weiteres File in den Speicher laden. Das ist der initrd.
Nun ist der Kernel so kompiliert, dass er eine RAM Disk kennt und das ext2 Filesystem versteht. Selbst, wenn diese beiden Dinge zum eigentlichen Betrieb nie wieder benötigt werden, müssen sie zum Booten im Kernel einkompiliert sein. (Sie benötigen aber zum Glück recht wenig Platz). Damit kennt nun der Kernel einen Standard-Weg, wie er ein bestimmtes Filesystem finden (mounten) kann. Dieses mountet er als Root Filesystem.
Das Root Filesystem ist bis jetzt aber nur im Hauptspeicher und der Kernel kennt Deine Platte immer noch nicht. Jetzt kommt ein spezielles Programm namens "/linurc" in der initrd zum Zuge. Der Kernel startet einfach dieses Programm und geht davon aus, dass es den Kernel schon irgendwie so konfiguriert, dass er danach das eigentliche Root Filesystem (auf der Platte) findet.
Meist muss linuxrc dafür nicht viel mehr machen, als z.B. den SCSI / IDE Treiber und den Treiber für reiserfs zu laden. Er kann aber auch ein Netzwerk-Interface konfigurieren und das Root Filesystem über nfs mounten.
Damit linuxrc (meist ein Shell Script) seine Arbeit tun kann muss der initrd die nötigen Teile mitbringen. Da wären (mindestens):
- - wenigstens eine Shell samt nötiger shared libs - - insmod - - die benötigten Module
Als letztes schreibt initrd die Device Nummer des eigentlichen Root Filesystems nach /proc/sys/kernel/real-root-dev. Dafür muss aber das proc Filesystem auch gemountet sein. Und hier kommt Dein mount Problem. Linuxrc versucht irgendwann /proc zu mounten und der mount Befehl gibt die Warnung aus. Normalerweise kann man mit der Option -n verhindern, dass mount oder umount /etc/mtab versuchen zu schreiben. Suse hat wohl an einer Stelle in /linuxrc vergessen, diese Option mitzugeben:
opi:/home # cat /mnt/linuxrc | grep mount mount -n -tproc proc /proc mount -n -tsysfs sysfs /sys > /dev/null 2>&1 mount -n -ttmpfs tmpfs /dev/shm umount -n /proc umount -n /sys umount /dev/shm <== das ist der Schuldige
Mit welchem Inhalt muss denn dann die /etc/mtab nach /mnt/etc/mtab (in die initrd hinein) kopiert bzw. geschrieben werden?
So, nun denke ich dargelegt zu haben, dass Du gar kein /etc/mtab in Deinem initrd brauchst. Du müsstest einfach den Fehler in linuxrc beheben. Dieser wird allerdings mit /sbin/mkinitrd erzeugt. Dort habe ich bei mir folgendes gefunden:
opi:/home # cat -n /sbin/mkinitrd |grep -C5 1337 1332 |done 1333 | 1334 |die() { 1335 | umount -n /proc 1336 | umount -n /sys 1337 | umount /dev/shm <== the culprit 1338 | exit \$1 1339 |} 1340 | 1341 |# Fallback root device number 1342 |rootdevn=$rootdevn
In Zeile 1337 fehlt einfach das -n.
Außerdem habe ich auch festgestellt, dass es unter /mnt/proc/ keine /mnt/proc/mounts (in der initrd) gibt.
natürlich. Wenn Dein System normal läuft, ist das proc Filesystem ja als /proc gemountet. Wenn der initrd in Betrieb ist, also in einer der ersten Phasen des Bootens, ist er als Root Filesystem (/) gemountet. Linuxrc mountet dann proc nach /proc (im initrd) und umountet /proc am Ende wieder.
Wenn es nun keine /proc/mounts in der initrd gibt, warum sollte dann /etc/mtab etwas in der initrd zu suchen haben?
siehe oben
Noch bei der Gelegenheit: Bei einem "mkinitrd" nach Thomas Hertweck wie folgt: - - - s n i p p - - - mkinitrd -k /boot/vmlinuz -i /boot/initrd-2.6.5-7.108-1 -s 1024x768 - - - - s n a p p - - - gibt es anschließend keine *.gz, und trotzdem ist die Datei komprimiert.
Linux/Unix gibt nicht sehr viel auf Endungen wie .gz. In der urspünglichen Philosophie steht der Typ eines Files oder des Inhalts irgendwie maschinenlesbar am Anfang des Files. Meist nennt man diesen Marker "magic number". Ganz durchhalten lies sich das nicht. Aber ein nützliches Kommando, wenn Du nicht weißt, was ein File ist, ist "file". Es benutzt den Inhalt des Files:
opi:/home # file /boot/initrd /boot/initrd-2.6.8-20040918095208-default /tmp/initrd.uncompressed /mnt/linuxrc /bin/bash /boot/initrd: symbolic link to `initrd-2.6.8-20040918095208-default' /boot/initrd-2.6.8-20040918095208-default: gzip compressed data, was "initrd_small", from Unix, max compression /tmp/initrd.uncompressed: Linux rev 1.0 ext2 filesystem data (mounted or unclean) /mnt/linuxrc: Bourne shell script text /bin/bash: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), stripped
Würde mich freuen, wenn Du diese Fragen auch noch beantworten würdest. Jetzt interessiert mich das alles nun auch noch. Wirklich.
Hat's geholfen?
Torsten -----BEGIN PGP SIGNATURE-----
hallo Torsten, jetzt hab ich schon fast ein schlechtes Gewissen, Dir soviel Arbeit zugemutet zu haben. Aber geholfen hat es natürlich. Ich habe ja zuvor wochenlang (meine Dümmlichkeit ?) bei Google, im Archiv und wer weiß wo sonst noch nach einer Antwort gesucht. Ich habe aber mehr Fragen als Versuche einer Antwort gefunden. M.E. sind Deine Angaben hier so einmalig und wertvoll, dass sie irgendwie/irgendwo - z.B. in der FAQ dieser Liste - oder auf Deiner Homepage (wenn Du eine hast(?) oder wo es sonst noch ginge ??? nachlesbar bleiben sollten. Dann würde sich sicher auch Deine Mühe und Arbeit hier noch besser "bezahlt" machen. Von mir ein ganz großes Dankeschön. Ich bin begeistert!!! Grüße Rolf
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 01 October 2004 17:10, Rolf Hoff wrote:
M.E. sind Deine Angaben hier so einmalig und wertvoll, dass sie irgendwie/irgendwo - z.B. in der FAQ dieser Liste - oder auf Deiner Homepage (wenn Du eine hast(?) oder wo es sonst noch ginge ??? nachlesbar bleiben sollten. Dann würde sich sicher auch Deine Mühe und Arbeit hier noch besser "bezahlt" machen.
Von mir ein ganz großes Dankeschön. Ich bin begeistert!!!
Formatier es doch mal hübsch in HTML (aber in lesbarem). Dann könnte ich es schon veröffentlichen. Ein bischen schon etwas älteres Zeug von mir findest Du unter http://zikkurat.net. Ich denke, noch bezahlter machte sich das Ganze, wenn es Eingang z.B. in die suse faq erhielte. Um das ordentlich zu machen, fehlt irgendwie immer die Zeit. Torsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBXXnowicyCTir8T4RAo+ZAJ95lGCdxB2vbs3YgaAilMh3tyYzvQCeIKYd FcsapvLDA1BzkONNiM9OYUs= =6pzu -----END PGP SIGNATURE-----
Hallo Torsten, hallo Leute, Am Freitag, 1. Oktober 2004 17:38 schrieb Torsten Förtsch:
On Friday 01 October 2004 17:10, Rolf Hoff wrote:
Thorsten Förtsch schrieb: [eine sehr gute Erklärung zum Thema initrd] Ich denke, noch bezahlter machte sich das Ganze, wenn es Eingang z.B. in die suse faq erhielte.
Ich betrachte das mal als Einladung ;-) Allerdings leidet das gesamte FAQ-Team an Zeitmangel, sodass es ein wenig dauern kann, bis Dein Text in der FAQ auftaucht. Der Fehler mit dem fehlenden -n bei umount in linuxrc besteht übrigens auch noch in der 9.2 beta [1], ich werde das wohl besser mal reporten ;-) Gruß Christian Boltz [1] Immerhin hat sich die Zeilennummer geändert ;-) --
Ohh jee ... ich will mein yast1 wieder *heul* :-)) Ich hab's noch, ich hab's noch... *freu* *hüpf* *SuSE 7.3 behalt* Bleib mir weg mit deiner neumodischen 7.sonstwas! [>> Konrad Neitzel, > Florian Gross und David Haller in suse-linux]
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday 03 October 2004 16:31, Christian Boltz wrote:
Am Freitag, 1. Oktober 2004 17:38 schrieb Torsten Förtsch:
On Friday 01 October 2004 17:10, Rolf Hoff wrote:
Thorsten Förtsch schrieb:
[eine sehr gute Erklärung zum Thema initrd]
Ich denke, noch bezahlter machte sich das Ganze, wenn es Eingang z.B. in die suse faq erhielte.
Ich betrachte das mal als Einladung ;-)
Allerdings leidet das gesamte FAQ-Team an Zeitmangel, sodass es ein wenig dauern kann, bis Dein Text in der FAQ auftaucht.
Der Fehler mit dem fehlenden -n bei umount in linuxrc besteht übrigens auch noch in der 9.2 beta [1], ich werde das wohl besser mal reporten ;-)
Wo gibt es denn 9.2 beta? Torsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBYBy4wicyCTir8T4RAnMGAKDK9FUA9EVkALc35vLYxd19oHpcBgCgw/H+ R5Yj4TLN5Xj5LunDossci5Y= =SPYh -----END PGP SIGNATURE-----
Christian Boltz schrieb:
Hallo Torsten, hallo Leute,
Am Freitag, 1. Oktober 2004 17:38 schrieb Torsten Förtsch:
On Friday 01 October 2004 17:10, Rolf Hoff wrote:
Thorsten Förtsch schrieb: [eine sehr gute Erklärung zum Thema initrd] Ich denke, noch bezahlter machte sich das Ganze, wenn es Eingang z.B. in die suse faq erhielte.
Ich betrachte das mal als Einladung ;-)
Allerdings leidet das gesamte FAQ-Team an Zeitmangel, sodass es ein wenig dauern kann, bis Dein Text in der FAQ auftaucht.
Der Fehler mit dem fehlenden -n bei umount in linuxrc besteht übrigens auch noch in der 9.2 beta [1], ich werde das wohl besser mal reporten ;-)
Gruß
Christian Boltz
[1] Immerhin hat sich die Zeilennummer geändert ;-)
hallo Torsten, Christian und alle ich habe mich in der Zwischenzeit weiter mit dem Thema beschäftigt. Als Ergebnis berichte ich wie folgt: Durch Ändern der Zeile 1337 in /sbin/mkinitrd, betreffend "umount /dev/shm" -> "umount -n /dev/shm" entfällt die Warnung wegen /etc/mtab nicht. Mit Bezug auf nachfolgende Zeilen 1333 uff der /sbin/mkinitrd habe ich festgestellt, dass die Warnung nur dann nicht mehr ausgegeben wird, wenn die Zeile "umount -n /proc" wie nachstehend deaktiviert wird. Allerdings wird auch dabei noch - wie auch in allen anderen Fällen - in der Zeile "exit \$1" nur: "exit \$0" ausgegeben. Für den Fehler habe ich keine Lösung gefunden. Bei der Gelegenheit die Warnung von mir: Niemand möge den *Mountbefehl* für */proc* deaktivieren. Das führt zum Absturz des Systems. | |die() { |# umount -n /proc | umount -n /sys | umount -n /dev/shm | exit \$1 |} | Mich würde es freuen, wenn mir noch jemand bestätigen würde, ob ich das so wie oben angezeigt machen kann - oder lieber nicht machen sollte und ob ich "exit \$0" unbeachtet lassen kann. Ohne genau zu wissen, warum (und ob das wirklich zutrifft?), will ich noch anmerken, dass auch beim Deaktivieren der Zeile mit "initrd=trace)" (in linuxrc und mkinitrd) die Fehlermeldung wegen /etc/mtab ausgeblendet blieb. Da gab es aber andere Fehlermeldungen in Bezug auf linuxrc (wahrscheinlich habe ich zu wenig oder zu viel - oder so etwa - deaktiviert?) Gruß Rolf
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday 03 October 2004 21:47, Rolf Hoff wrote:
Bei der Gelegenheit die Warnung von mir: Niemand möge den *Mountbefehl* für */proc* deaktivieren. Das führt zum Absturz des Systems.
| |die() { |# umount -n /proc | umount -n /sys | umount -n /dev/shm | exit \$1 |} |
Das das zu einem Panic führt ist recht verständlich. Ich habe mal irgendwo gelesen, dass nach Beendigung der /linuxrc *KEIN* Filesystem mehr gemountet sein darf. Wenn Du den umount ausbaust, bleibt /proc gemountet. Der Panic ist aber nicht schlimm. Es ist eh noch kein Filesystem gemountet, also kann auch kein Filesystem kaputt gehen.
Mich würde es freuen, wenn mir noch jemand bestätigen würde, ob ich das so wie oben angezeigt machen kann - oder lieber nicht machen sollte und ob ich "exit \$0" unbeachtet lassen kann.
Hier habe ich Deine Ausführungen nicht verstanden. "exit $1" beendet einfach das Script und gibt als Return Code den ersten Parameter zurück. Irgendwo im Text steht dann wahrscheinlich "die 0" oder "die 1". Damit wird dann alles ungemountet (schreckliches Wort) und das Script mit 0 bzw. 1 beendet.
Ohne genau zu wissen, warum (und ob das wirklich zutrifft?), will ich noch anmerken, dass auch beim Deaktivieren der Zeile mit "initrd=trace)" (in linuxrc und mkinitrd) die Fehlermeldung wegen /etc/mtab ausgeblendet blieb. Da gab es aber andere Fehlermeldungen in Bezug auf linuxrc (wahrscheinlich habe ich zu wenig oder zu viel - oder so etwa - deaktiviert?)
Also, ich weiß nicht, was Du da gemacht hast. Hier der Ausschnitt aus meiner /linuxrc: for o in $(cat /proc/cmdline); do case $o in initrd=trace) set -x ;; esac done Das Stück Code liest die Kommandozeile, mit der der Kernel vom Boot Loader gestartet wurde und sucht darin nach "initrd=trace". Wenn dieser Parameter übergeben wurde, wird "set -x" ausgeführt und damit die Shell in den Trace Mode geschaltet. In diesem Modus gibt sie jedes Kommando, das sie ausführt nochmal zusätzlich aus. Damit kannst Du dann genau sehen, nach welchem Kommando Deine Fehlermeldung auftritt. Die Kernel Kommandozeile kannst Du, wenn Du grub benutzt, einfach am Boot Prompt setzen. Normalerweise installiert sich ein Suse Linux so, dass nach dem Einschalten des Rechners ein Bildschirm erscheint, in dem man mit den Pfeiltasten ein System auswählen kann. Wenn Du noch ein Windows auf der Platte hast, dann kannst Du hier auch Windows auswählen. In diesem Menu wählst du nun Dein Linux. Dann gibst Du einfach mit der Tastatur "initrd=trace" (ohne die ") ein und drückst auf ENTER. Dann startet der Kernel und irgendwann auch mal /linuxrc. /linuxrc liest die Kernel Kommandozeile findet "initrc=trace"... weiter siehe oben. Torsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBYF3nwicyCTir8T4RAjd5AKCyHV9rCfowlI9hk76MlhAHjVYd+wCgm2la cmcaB5l6o37OcR6oJwFLxO8= =FtMs -----END PGP SIGNATURE-----
Torsten Förtsch schrieb:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sunday 03 October 2004 21:47, Rolf Hoff wrote:
Bei der Gelegenheit die Warnung von mir: Niemand möge den *Mountbefehl* für */proc* deaktivieren. Das führt zum Absturz des Systems.
| |die() { |# umount -n /proc | umount -n /sys | umount -n /dev/shm | exit \$1 |} |
Das das zu einem Panic führt ist recht verständlich. Ich habe mal irgendwo gelesen, dass nach Beendigung der /linuxrc *KEIN* Filesystem mehr gemountet sein darf. Wenn Du den umount ausbaust, bleibt /proc gemountet.
Der Panic ist aber nicht schlimm. Es ist eh noch kein Filesystem gemountet, also kann auch kein Filesystem kaputt gehen.
Nicht der deaktivierte "umount"-Befehl führt zum Panic, sondern der deaktivierte "mount"-Befehl. siehe oben: -> "# umount -n /proc" bleibt schadlos, abgesehen davon, dass dann /proc nicht umountet wird. [ . . . .] Ich beziehe hier mal die Mail von David Haller mit ein: - - - - s n i p p - -> [..]
Mit Bezug auf nachfolgende Zeilen 1333 uff der /sbin/mkinitrd habe ich festgestellt, dass die Warnung nur dann nicht mehr ausgegeben wird, wenn die Zeile "umount -n /proc" wie nachstehend deaktiviert wird.
Aendere die Zeile in
umount -n /proc >/dev/null 2>&1
-dnh
- - - - - s n a p p - - - Diese Änderung konnte die Warnung bezüglich /etc/mtab nicht beenden. Vielen Dank für die Hilfe, David. Dies vorausgeschickt teile ich nunmehr noch mit: Ich habe jetzt die /sbin/mkinitrd (bei mir die Zeilen 1337 uff) sowie die linuxrc geändert von | |die() { | umount -n /proc | umount -n /sys | umount /dev/shm | exit \$1 |} | nach (neue Fassung): | |die() { | umount /proc | umount /sys | umount /dev/shm | exit \$1 |} | Außerdem habe ich in /etc/lilo.conf die Appendzeile ergänzt mit "initrd=trace". Auf dem Startbildschirm wird danach u.a. angezeigt (in dmesg bzw. /var/log/boot.msg nicht enthalten): [ - - - s n i p p - - ] + local.root + [ -n ] die 0 exit 0 umount /proc umount /sys umount /dev/shm [- - - s n a p p - - ] Die Warnung wegen /etc/mtab (siehe oben) wird nicht mehr ausgegeben. Damit ist das von mir angestrebte Ziel erreicht. Zwischenzeitlich habe ich noch festgestellt, dass allein die Änderung der Zeile "umount -n /proc" in neu "umount /proc" ausreicht, um die Warnung zu beseitigen. Nunmehr stellt sich allerdings eine Frage, für die mein Wissen nicht ausreicht: Bisher wurde behauptet, dass in der Zeile "umount /shm" die Angabe "-n" fehlt. Mir scheint jedoch jetzt, dass vielmehr in den beiden anderen Zeilen (zumindest für /proc) die Angabe "-n" nicht erforderlich ist, ja sogar stört (siehe Warning:...). Ich werde zwar mit Interesse weiter mitlesen, aber mitreden kann ich dabei nun leider gar nicht mehr. Unter der Voraussetzung, dass mir hier nicht noch etwas anderes mitgeteilt wird, werde ich nun wie oben angezeigt verfahren. Das Ergebnis und die Antwort auf die ursprüngliche Frage dürfte damit zum ersten Mal im Internet gefunden bzw. gegeben worden sein. Vielen Dank an alle, die dabei so interessiert mitgemacht haben. Ich hoffe doch, dass dafür gesorgt wird, dass es einen angemessenen Platz findet (einschließlich der Antworten auf die noch offenen Diskussionsfragen). beste Grüße an alle Rolf
Hallo, Am Sun, 03 Oct 2004, Rolf Hoff schrieb: [..]
Mit Bezug auf nachfolgende Zeilen 1333 uff der /sbin/mkinitrd habe ich festgestellt, dass die Warnung nur dann nicht mehr ausgegeben wird, wenn die Zeile "umount -n /proc" wie nachstehend deaktiviert wird.
Aendere die Zeile in umount -n /proc >/dev/null 2>&1 -dnh -- Boys will be boys, and so will a lot of middle-aged men. -- Kin Hubbard
Hi, On Sun, 2004-10-03 at 21:47, Rolf Hoff wrote:
ich habe mich in der Zwischenzeit weiter mit dem Thema beschäftigt. Als Ergebnis berichte ich wie folgt:
Durch Ändern der Zeile 1337 in /sbin/mkinitrd, betreffend "umount /dev/shm" -> "umount -n /dev/shm" entfällt die Warnung wegen /etc/mtab nicht.
Bei mir schon... MFG, Rohan Lean
David Haller schrieb:
Hallo,
Am Tue, 28 Sep 2004, Rolf Hoff schrieb:
David Haller schrieb: [..]
Dir fehlt in der initrd die /etc/mtab und/oder es versucht etwas zu frueh (eben bevor / und damit /etc/ gemountet ist) zu (un-)mounten.
Aber: es ist eine Warnung und in diesem Falle wohl ignorierbar. [..] OK, es ist nur eine Warnung, aber trotzdem, wie kriege ich /etc/mtab in die initrd rein? Mit der Appendzeile von lilo? Oder wie sonst? Wie lautet der Text bzw. das Kommando?
Das weiss ich leider auch nicht, da ich keine initrd verwende.
Schau aber erstmal, wo genau die Warnung kommt, bzw. maile mal die ~10 Zeilen direkt vor der Meldung.
-dnh
hallo David hier die nachgefragten Zeilen von /var/log/boot.msg sowie meine lilo.conf und die initrd-2.6.5-7.108: Die Warnung in /var/log/boot.msg wurde von mir manuell nachgetragen, um die Zeilen vor der Warnung damit zu markieren (im Protokoll wird ja die Warnung nicht ausgedruckt, sie wird nur auf dem Startbildschirm angezeigt): /var/log/boot.msg (auszugsweise): - - - - s n i p p - - - <4>hda: max request size: 128KiB <6>hda: 39876480 sectors (20416 MB) w/1966KiB Cache, CHS=39560/16/63 <4>hda: cache flushes not supported <6> hda: hda1 hda2 [ . . . .] <6>input: AT Translated Set 2 keyboard on isa0060/serio0 <6>NET: Registered protocol family 2 <6>IP: routing cache hash table of 8192 buckets, 64Kbytes <6>TCP: Hash tables configured (established 262144 bind 65536) <6>NET: Registered protocol family 1 <6>ACPI: (supports S0 S1 S4bios S5) <5>RAMDISK: Compressed image found at block 0 <4>VFS: Mounted root (ext2 filesystem). <5>SCSI subsystem initialized <6>scsi0 : AdvanSys SCSI 3.3GJ: PCI Ultra: IO 0xDC00-0xDC0F, IRQ 0x5 - - - - - - warning: can't open /etc/mtab: no such file or directory warning: can't open /etc/mtab: no such file or directory - - - - <4>VFS: Mounted root (ext2 filesystem) readonly. <5>Trying to move old root to /initrd ... failed <5>Unmounting old root <5>Trying to free ramdisk memory ... okay <6>Freeing unused kernel memory: 172k freed <6>Adding 512024k swap on /dev/hda1. Priority:42 extents:1 <6>device-mapper: 4.1.0-ioctl (2003-12-10) initialised: dm@uk.sistina.com <6>subfs 0.9 Kernel logging (ksyslog) stopped. Kernel log daemon terminating. Boot logging started on /dev/tty1(/dev/console) at Wed Sep 29 12:37:32 2004 - - - - s n a p p - - - - - - s n i p p- - - ro999:~ # mkinitrd -k /boot/vmlinuz -i /boot/initrd-2.6.5-7.108-1 -s 1024x768 Root device: /dev/hda2 (mounted on / as ext2) Module list: advansys Kernel image: /boot/vmlinuz Initrd image: /boot/initrd-2.6.5-7.108-1 Shared libs: lib/ld-2.3.3.so lib/libc.so.6 lib/libselinux.so.1 Modules: kernel/drivers/scsi/scsi_mod.ko kernel/drivers/scsi/sd_mod.ko kernel/drivers/scsi/advansys.ko Bootsplash: SuSE (1024x768) Run lilo now to update the boot loader configuration. ro999:~ # lilo Added Linux * Added Failsafe ro999:~ # - - - - - - -s n a p p - - - (Hinweis: ln -s /boot/initrd-2.6.5-7.108-1 /boot/initrd liegt an) - - - s n i p p - - - ro999:~ # cat /etc/lilo.conf # Modified by YaST2. Last modification on Thu Jul 1 07:22:35 2004 menu-scheme = Wb:kw:Wb:Wb default = Linux timeout = 80 message = /boot/message lba32 change-rules reset read-only prompt boot = /dev/hda image = /boot/vmlinuz ###Don't change this comment - YaST2 identifier: Original name: linux### label = Linux initrd = /boot/initrd root = /dev/hda2 append = "resume=/dev/hda1 splash=silent desktop" vga = 0x317 image = /boot/vmlinuz ###Don't change this comment - YaST2 identifier: Original name: failsafe### label = Failsafe initrd = /boot/initrd root = /dev/hda2 append = "ide=nodma apm=off acpi=off vga=normal noresume nosmp noapic maxcpus=0 3" ro999:~ # - - - - - s n a p p - - - - - - - - s n i p p - - - ro999:~ # ls -l /boot/* -rw-r--r-- 1 root root 512 2004-07-01 09:22 /boot/backup_mbr -rw-r--r-- 1 root root 512 2004-09-03 20:26 /boot/boot.0300 lrwxrwxrwx 1 root root 26 2004-09-29 12:06 /boot/initrd -> /boot/initrd-2.6.5-7.108-1 -rw-r--r-- 1 root root 1224503 2004-09-29 11:32 /boot/initrd-2.6.5-7.108-1 -rw------- 1 root root 148992 2004-09-29 11:32 /boot/map -rw-r--r-- 1 root root 84480 2004-07-20 19:46 /boot/message -rw-r--r-- 1 root root 598217 2004-09-03 20:24 /boot/System.map-2.6.5-7.108-1 lrwxrwxrwx 1 root root 27 2004-09-03 20:26 /boot/vmlinuz -> /boot/vmlinuz-2.6.5-7.108-1 -rw-r--r-- 1 root root 1179674 2004-09-03 20:25 /boot/vmlinuz-2.6.5-7.108-1 ro999:~ # - - - - s n a p p - - - - /etc/mtab und /proc/mounts sind in meiner Mail vom 25.09.04 enthalten. /etc/fstab ist in meiner Mail vom 28.09.04. Ergänzend dazu : ro999:~ # ls -l /etc/mtab -rw-r--r-- 1 root root 247 2004-09-29 11:32 /etc/mtab ro999:~ # mount /etc/mtab mount: Konnte /etc/mtab nicht in /etc/fstab oder /etc/mtab finden ro999:~ # Für die Hilfe schon mal im voraus vielen Dank. Gruß Rolf
participants (6)
-
Christian Boltz -
David Haller -
Ekkard Gerlach -
Rohan Lean -
Rolf Hoff -
Torsten Förtsch