Hallo LUG,
ich habe hier ein Problem, bei welchem ich irgendwie nicht weiterkomme:
RAMDISK: Compressed image found at block 0 Time: tsc clocksource has been installed. VFS: Mounted root (ext2 filesystem). Freeing unused kernel memory: 136k freed Failed to execute /sbin/init. Attempting defaults... Kernel panic - not syncing: No init found. Try passing init= option to kernel.
Wenn init im rootfs liegt und das rootfs eingebunden wurde ... woran könnte es dann noch liegen? Ich habe hier irgendwie keinen Ansatz und bin über jeden Hinweis dankbar.
Steffen Kowalski steffen.kowalski@selfdelve.com (Mo 16 Apr 2007 11:26:15 CEST):
Hallo LUG,
ich habe hier ein Problem, bei welchem ich irgendwie nicht weiterkomme:
RAMDISK: Compressed image found at block 0 Time: tsc clocksource has been installed. VFS: Mounted root (ext2 filesystem). Freeing unused kernel memory: 136k freed Failed to execute /sbin/init. Attempting defaults... Kernel panic - not syncing: No init found. Try passing init= option to kernel.
Wenn init im rootfs liegt und das rootfs eingebunden wurde ... woran könnte es dann noch liegen? Ich habe hier irgendwie keinen Ansatz und bin über jeden Hinweis dankbar.
Bin mir jetzt nicht so sicher, wie die Meldungen normalerweise aussehen, aber kann es sein, daß er das INIT der Initrd meint? Denn wenn es wirklich das Rootfs wäre, täte er statt init irgendwann eine Shell starten, denke ich.
Hallo Heiko,
Am Montag, 16. April 2007 13:14 schrieb Heiko Schlittermann:
Bin mir jetzt nicht so sicher, wie die Meldungen normalerweise aussehen,
Danach kommen (glaube ich) die runlevel (je nach inittab)
aber kann es sein, daß er das INIT der Initrd meint? Denn wenn es
^^^^^^^^^^^^^^^^^^^ ? Du meinst das bin /sbin/init? Ich denke darum geht es. Gibt's da noch etwas anderes - kernel intern?
wirklich das Rootfs wäre, täte er statt init irgendwann eine Shell starten, denke ich.
Ich glaube meine Linuxkenntnisse sind zu schlecht. Was genau startet der kernel eigentlich zuerst, init oder eine shell?
Steffen Kowalski steffen.kowalski@selfdelve.com (Mo 16 Apr 2007 13:28:27 CEST):
Hallo Heiko,
Am Montag, 16. April 2007 13:14 schrieb Heiko Schlittermann:
Bin mir jetzt nicht so sicher, wie die Meldungen normalerweise aussehen,
Danach kommen (glaube ich) die runlevel (je nach inittab)
aber kann es sein, daß er das INIT der Initrd meint? Denn wenn es
^^^^^^^^^^^^^^^^^^^? Du meinst das bin /sbin/init? Ich denke darum geht es. Gibt's da noch etwas anderes - kernel intern?
Ich meine /sbin/init, vom jeweiligen Root-Filesystem, welches am Anfang ja die Ramdisk ist. Aber ich glaube mich zu erinnern, daß bei der Initrd (richtiges Filesystem, ext2, CRAMFS oder ähnliches) nach 'linuxrc' gesucht wird, bei den aktuellen Initrd (die nur noch ein CPIO-Archiv sind) aber noch einer Form von init.
wirklich das Rootfs wäre, täte er statt init irgendwann eine Shell starten, denke ich.
Ich glaube meine Linuxkenntnisse sind zu schlecht. Was genau startet der kernel eigentlich zuerst, init oder eine shell?
Sobald ein Filesystem da ist, sollte der Kernel ($KERNEL_SOURCE/init/main.c) suchen:
run_init_process("/sbin/init"); run_init_process("/etc/init"); run_init_process("/bin/init"); run_init_process("/bin/sh");
panic("No init found. Try passing init= option to kernel.");
Hallo Heiko,
Am Montag, 16. April 2007 13:55 schrieb Heiko Schlittermann:
Ich meine /sbin/init, vom jeweiligen Root-Filesystem, welches am Anfang ja die Ramdisk ist. Aber ich glaube mich zu erinnern, daß bei der Initrd (richtiges Filesystem, ext2, CRAMFS oder ähnliches) nach 'linuxrc' gesucht wird, bei den aktuellen Initrd (die nur noch ein CPIO-Archiv sind) aber noch einer Form von init.
Die aktuellen Kernel suchen scheinbar überhaupt nicht mehr nach initrc - zumindest steht das nirgendwo.
Sobald ein Filesystem da ist, sollte der Kernel ($KERNEL_SOURCE/init/main.c) suchen:
run_init_process("/sbin/init"); run_init_process("/etc/init"); run_init_process("/bin/init"); run_init_process("/bin/sh"); panic("No init found. Try passing init= option to kernel.");
Ach Heiko ;) Ich dachte ich könnte so leben wie unsere Katze und komme um die Kernelquellen drumherum ;) Aber Du hast ja recht!
Hi Steffen,
On Mon, Apr 16, 2007 at 13:28:27 +0200, Steffen Kowalski wrote:
aber kann es sein, dass er das INIT der Initrd meint? Denn wenn es
Du meinst das bin /sbin/init? Ich denke darum geht es. Gibt's da noch etwas anderes - kernel intern?
Kernelintern gibt es da nichts, aber es gibt unterschiedliche Methoden, wie man eine initiale Ramdisk anfassen kann und von dort aus aufs eigentliche Rootfilesystem wechselt:
1 "Old style" initrd mit terminierendem linuxrc:
Die initiale Ramdisk ist ein gzip-komprimiertes ext2-Image. Darin erwartet der Kernel eine ausfuehrbare Datei /linuxrc. Der linuxrc-Prozess laeuft sozusagen als pre-init, laedt z.B. wichtige Kernelmodule und darf sich auch wieder beenden. Danach mountet der Kernel selbst das eigentliche Rootfilesystem, was ihm vom Bootloader ueber root=... mitgeteilt wurde und startet dort /sbin/init mit PID 1. Alternativ kann linuxrc das Rootfilesystem finden und ueber /proc/sys/kernel/real-root-dev dem Kernel mitteilen, was er spaeter zu mounten hat. Nach dem Booten steht die initiale Ramdisk optional als normale Ramdisk, gemountet auf /initrd zur Verfuegung.
2 "Old style" initrd mit linuxrc als init:
Die initiale Ramdisk ist ein gzip-komprimiertes ext2-Image. Per Bootloader bekommt der Kernel die Argumente root=/dev/ram0 init=/linuxrc. In diesem Fall behandelt der Kernel die Ramdisk bereits als echtes Rootfilesystem und /linuxrc als echtes init, das sich nicht beenden darf. Hier hat linuxrc die Aufgabe, das spaetere Rootfilesystem selbst zu mounten, den Wechsel darauf selbst vorzunehmen und sich abschliessend -- unter Beibehaltung der PID 1 -- mit dem dortigen /sbin/init zu ueberlagern (exec). Je nach Art des Rootfilesystemwechsels kann wie im Fall 1 die initiale Ramdisk nach dem Booten als Ramdisk weiterbenutzt werden.
3 Initramfs (als Teil vom "early userspace"):
Die initiale Ramdisk ist ein gzip-komprimiertes cpio-Archiv. Darin erwartet der Kernel eine ausfuehrbare Datei /init (nicht /sbin/init). Diese wird wie im Fall 2 als echtes init angesehen und hat die gleichen Aufgaben wie linuxrc im Fall 2. Waehrend des Rootfilesystemwechsels sollte der ramfs-Inhalt komplett geloescht werden, damit der zugehoerige Speicher freigegeben wird[1]. Im Gegensatz zu "normalen" /dev/ram*-Ramdisks belegt ein ramfs immer nur soviel Speicher, wie Dateien im ramfs liegen.
Ich glaube meine Linuxkenntnisse sind zu schlecht. Was genau startet der kernel eigentlich zuerst, init oder eine shell?
Er startet init. Wenn er eine Shell anstelle von /sbin/init starten soll, gibt man per Bootloader etwa init=/bin/bash an. Ohne entsprechende Sonderbehandlung in /linuxrc (Fall 2) bzw. /init (Fall 3) funktioniert "init=/bin/bash" also nur im Fall 1 oder ganz ohne initiale Ramdisk.
[1] Siehe Applet "switch_root" im Source von busybox.
Gruss, Chris
Christian Perle chris@linuxinfotag.de (Mo 16 Apr 2007 15:10:46 CEST):
Ich glaube meine Linuxkenntnisse sind zu schlecht. Was genau startet der kernel eigentlich zuerst, init oder eine shell?
Er startet init. Wenn er eine Shell anstelle von /sbin/init starten soll, gibt man per Bootloader etwa init=/bin/bash an. Ohne entsprechende Sonderbehandlung in /linuxrc (Fall 2) bzw. /init (Fall 3) funktioniert "init=/bin/bash" also nur im Fall 1 oder ganz ohne initiale Ramdisk.
Ich denke, daß "init=/bin/bash" auch geht, wenn da ein initramfs am Start ist. Möglicherweise hängt es vom initramfs-Creator ab (hier: Debian, initramfs-tools), -- aber, nee, wenn dann hinge es vom Kernel ab. Also gehe ich mal davon aus, daß ein "init=/bin/bash" sich ausdrücklich nicht auf den early userspace bezieht.
Hallo Heiko,
Am Montag, 16. April 2007 15:57 schrieb Heiko Schlittermann:
Ich denke, daß "init=/bin/bash" auch geht, wenn da ein initramfs am Start ist. Möglicherweise hängt es vom initramfs-Creator ab (hier: Debian, initramfs-tools), -- aber, nee, wenn dann hinge es vom Kernel ab. Also gehe ich mal davon aus, daß ein "init=/bin/bash" sich ausdrücklich nicht auf den early userspace bezieht.
Bei einem cpio Archiv wird die Kerneloption init=something ignoriert. Es *muß* ein nichtterminierendes Binary /init existieren. Für das bash Beispiel also ein ln -s /bin/bash /init.
Das mit dem "early userspace" habe ich aber noch nicht ganz verstanden. Irendwie hängt das alles mit der klibc (und weitere Zusätze wie z.Bsp busybox) zusammen, welche aber nicht benötigt wird - sozusagen umgeht/überspringt/ignoriert man den early userspace.?
Also ich habe auf meinem Gentoo-Linux-PC das ganze initrc weggelassen / weglassen können. Das wäre auch meine Frage an Dich, ob du nicht ganz auf das initrc verzichten möchtest. Das brauchst du ja nur, falls du bereits beim booten bestimmte userspace-funktionen benutzen willst. z.B. highres-textmodi, netzwerk, grafischen Bootbildschirm. Ich habe es mir einfach gemacht und das alles weggelassen, da ich ja eh in den x-server durchstarten möchte.
Ulrich.
Steffen Kowalski schrieb:
Hallo Heiko,
Am Montag, 16. April 2007 15:57 schrieb Heiko Schlittermann:
Ich denke, daß "init=/bin/bash" auch geht, wenn da ein initramfs am Start ist. Möglicherweise hängt es vom initramfs-Creator ab (hier: Debian, initramfs-tools), -- aber, nee, wenn dann hinge es vom Kernel ab. Also gehe ich mal davon aus, daß ein "init=/bin/bash" sich ausdrücklich nicht auf den early userspace bezieht.
Bei einem cpio Archiv wird die Kerneloption init=something ignoriert. Es *muß* ein nichtterminierendes Binary /init existieren. Für das bash Beispiel also ein ln -s /bin/bash /init.
Das mit dem "early userspace" habe ich aber noch nicht ganz verstanden. Irendwie hängt das alles mit der klibc (und weitere Zusätze wie z.Bsp busybox) zusammen, welche aber nicht benötigt wird - sozusagen umgeht/überspringt/ignoriert man den early userspace.?
Lug-dd maillist - Lug-dd@mailman.schlittermann.de http://mailman.schlittermann.de/mailman/listinfo/lug-dd
Hallo Ulrich,
Am Mittwoch, 18. April 2007 18:54 schrieb Ulrich Schmidt:
Das brauchst du ja nur, falls du bereits beim booten bestimmte userspace-funktionen benutzen willst. z.B. highres-textmodi, netzwerk, grafischen Bootbildschirm.
Es gibt auch andere Anwendungsfälle. Z.Bsp. wenn alles aus dem RAM laufen soll, also ohne disk's, nfs, cd o.ä. Ein interessantes Projekt ist z.Bsp. http://diet-pc.sourceforge.net/
Hallo Christian,
erst mal Danke für Deine umfangreiche Antwort. Das sind erst mal etwas Mehr an Informationen, als ich vertragen kann ;)
Am Montag, 16. April 2007 15:10 schrieb Christian Perle:
Kernelintern gibt es da nichts, aber es gibt unterschiedliche Methoden, wie man eine initiale Ramdisk anfassen kann und von dort aus aufs eigentliche Rootfilesystem wechselt:
Das ist mir alles neu. Wie initialisiert man eigentlich die drei Methoden? Ich vermute es wird ein fall back von Variante 3 über 2 zu 1 durchgeführt?
2 "Old style" initrd mit linuxrc als init:
Ich dachte diese Variante zu kennen.
Die initiale Ramdisk ist ein gzip-komprimiertes ext2-Image. Per Bootloader bekommt der Kernel die Argumente root=/dev/ram0 init=/linuxrc. In diesem Fall behandelt der Kernel die Ramdisk bereits als echtes Rootfilesystem und /linuxrc als echtes init, das sich nicht beenden darf. Hier hat linuxrc die Aufgabe, das spaetere Rootfilesystem selbst zu mounten, den Wechsel darauf selbst vorzunehmen und sich abschliessend -- unter Beibehaltung der PID 1 -- mit dem dortigen /sbin/init zu ueberlagern (exec). Je nach Art des Rootfilesystemwechsels kann wie im Fall 1 die initiale Ramdisk nach dem Booten als Ramdisk weiterbenutzt werden.
Wenn der Rootfilesystemwechsel ausgelassen wird, 'sieht' man dann dann den Root-Mount-Point (in der Art /dev/ram0 on /)? Ich habe hier folgende Ausgabe:
root@c17:~# mount proc on /proc type proc (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620)
Hi Steffen,
On Tue, Apr 17, 2007 at 10:35:09 +0200, Steffen Kowalski wrote:
Kernelintern gibt es da nichts, aber es gibt unterschiedliche Methoden, wie man eine initiale Ramdisk anfassen kann und von dort aus aufs eigentliche Rootfilesystem wechselt:
Das ist mir alles neu. Wie initialisiert man eigentlich die drei Methoden? Ich vermute es wird ein fall back von Variante 3 ueber 2 zu 1 durchgef?hrt?
Nein. Jede Methode ist durch Kernel-Bootparameter und Aufbau der initrd bestimmt. Das Problem ist eher, dass jeder Distributor seine eigenen Vorstellungen vom Aufbau und Ablauf der initrd hat.
Wenn der Rootfilesystemwechsel ausgelassen wird, 'sieht' man dann dann den Root-Mount-Point (in der Art /dev/ram0 on /)? Ich habe hier folgende Ausgabe:
root@c17:~# mount proc on /proc type proc (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620)
Die Ausgabe von "mount" ist nicht immer aussagekraeftig, da dort nur der Inhalt von /etc/mtab ausgewertet wird. Diese Datei muss vom Userspace aktuell gehalten werden (normalerweise von /bin/mount und /bin/umount), gibt also nicht zwingend den Ist-Zustand der Mounts wieder. Mit "cat /proc/mounts" kommt die Information direkt aus dem Kernel. Allerdings ist der /proc/mounts-Eintrag bzgl. Rootfilesystem nicht besonders informativ:
rootfs / rootfs rw 0 0
Jedenfalls ist in Methode 1 und 2 /dev/ram0 auf / gemountet. In Methode 3 (ramfs) gibt es kein explizites Blockdevice. Das gibt es bei ramfs und tmpfs prinzipiell nicht. Siehe auch /usr/src/linux/Documentation/filesystems/tmpfs.txt
Gruss, Chris
lug-dd@mailman.schlittermann.de
-
Christian Perle -
Heiko Schlittermann -
Steffen Kowalski -
Ulrich Schmidt