* On Tue, 29 Jul 2003 at 10:23 +0200, J?rgen Vollmer wrote:

ich habe gerade einen neuen SuSE-Kernel übersetzt (linux-2.4.21.SuSE-1.tar.bz2), so wie ich es bisher auch gemacht habe. Habe "make clone-config" benutzt ausgehend von dem "Standard" SuSE 8.2 SMP-Kernel und dann nochmal "make menuconfig", um zu sehen, ob alles ok ist .

Eine initrd erzeugt: creating initrd "/boot/initrd-2.4.21-0-SuSE-SMP" for kernel "/boot/vmlinuz-2.4.21-0-SuSE-SMP" (version 2.4.21-0-SuSE) - insmod scsi_mod (kernel/drivers/scsi/scsi_mod.o) - insmod aic7xxx (kernel/drivers/scsi/aic7xxx/aic7xxx.o) - insmod reiserfs (kernel/fs/reiserfs/reiserfs.o) - splash picture (1024x768)

Hast Du irgendwann im Betrieb mal vor, das SCSI-Subsystem zu deaktivieren, den Controller zu deaktivieren oder ReiserFS rauszuschmeissen? Mir sehen alle 3 so aus, als wären sie zum Betrieb Deines Rechners zwingend notwendig. Wenn dem so ist - warum kompilierst Du diese quasi lebensnotwendigen Sachen als Modul? /apm -- GPG welcome, request public key: mailto:adalbert+key@lopez.at

Jürgen Vollmer schrieb:

[...] kmod: faild to exec /sbin/modprobe -s -k block-major-8, errno=2 VFS: cannot open root device "sda1" or 08:01 kernel panic: VFS unable to mount root fs on 08:01

was ist denn da nur los? was mache ich da falsch?

Falsches Root-Device angegeben? Keine Unterstuetzung fuer das Root-Filesystem im Kernel oder der initrd? Warum alles als Modul realisiert ist, wenn man eh einen eigenen Kernel bastelt, bleibt mir allerdings schleicher- haft... CU, Th.

Jürgen Vollmer schrieb:

[...] nix derartiges, ich frage mich nur wo /sbin/modprobe eigentlich zu dem Zeitpunkt vorhanden sein soll. Auf der RAM-Disk ist es jedenfalls nicht.

Die Funktionsweise einer initrd ist ungefaehr wie folgt (etwas ver- kuerzt dargestellt): Der Bootloader (meist lilo oder grub) laedt neben dem eigentlichen Kernel auch die initrd in den Speicher, startet dann den Kernel, wobei dem Kernel mitgeteilt wird, dass es eine initrd gibt und wo sie zu finden ist. Die initrd wird entkomprimiert und der Kernel mountet sie dann als temporaeres Root-Filesystem. Dann wird auto- matisch das Programm /linuxrc mit Root-Rechten gestartet, und das ist eben der Trick an der Geschichte. Dieses "Programm" kann ein Executable sein oder auch ein Shell-Skript, es muss nur alles Noetige (also auch evtl. Bibliotheken etc.) in der initrd vorhanden sein, um es ausfuehren zu koennen. linuxrc kann nun alle Dinge tun, die erforderlich sind, um das eigentliche Root-Filesystem (das waere die Option root=/dev/???? beim Boot-Loader) zu mounten, u.a. eben ein SCSI-Modul laden oder die Unterstuetzung fuer das Root- Filesystem bereitstellen. Beendet sich linuxrc, so wird das tem- poraere Root-Filesystem wieder unmounted und das Booten geht wie Du es gewohnt bist weiter. Da nun alle erfoderlichen Unterstuetzun- gen zur Verfuegung stehen, kann nun auch das eigentliche Root- Filesystem ordnungsgemaess gemountet werden. Dann steht Dir fuer weitere Vorgaenge auch /sbin/modprobe zur Verfuegung. Ich denke, die Antwort auf Deine obige Frage steckt quasi in der Funktions- weise von /linuxrc der initrd. Hoffe, dier Erklaerung hilft Dir ein wenig weiter... Gruesse, Thomson

Jürgen Vollmer schrieb:

[...] zu diesem Zeitpunkt soll aber anscheinend schon /sbin/modprobe ausgeführt werden, also müsste es auf der initrd sein. Denn es sollen jetzt ja SCSI und reiserfs Module geladen werden.

Hast Du es Dir denn mal angeschaut? Hast Du meine Mail eigentlich verstanden? Hier ist also mal der Inhalt (gekuerzt) meiner initrd (entkomprimiert und gemountet), vielleicht wird es dann verstaend- licher; ich habe gedacht, Du wuerdest das vielleicht mal selbst machen: $> ll drwxr-xr-x 5 root root 1024 2003-06-19 18:58 . drwxr-xr-x 23 root root 4096 2003-08-01 11:30 .. drwxr-xr-x 2 root root 1024 2003-06-19 18:58 bin drwxr-xr-x 2 root root 1024 2003-06-19 18:58 dev drwxr-xr-x 3 root root 1024 2003-06-19 18:58 lib -rwxr-xr-x 1 root root 116 2003-06-19 18:58 linuxrc Wenn diese initrd als temporaeres Root-Filesystem gemountet wurde, wird /linuxrc ausgefuehrt. linuxrc ist nichts anderes als ein Shell-Skript mit folgendem Inhalt: #! /bin/sh export PATH=/bin echo 'Loading module jbd ...' insmod jbd echo 'Loading module ext3 ...' insmod ext3 Die Programme sh und insmod muessen natuerlich ebenfalls in der initrd enthalten sein, wie ich auch schon in meiner letzten Mail gesagt habe. Und siehe da: $> ll bin/ drwxr-xr-x 2 root root 1024 2003-06-19 18:58 . drwxr-xr-x 5 root root 1024 2003-06-19 18:58 .. -rwxr-xr-x 1 root root 477562 2003-06-19 18:58 insmod -rwxr-xr-x 1 root root 154884 2003-06-19 18:58 insmod.old -rwxr-xr-x 1 root root 54476 2003-06-19 18:58 sh Nun brauchen wir natuerlich noch die Module, die man ja explizit in die initrd aufgenommen hat (hier in diesem Falle jbd und ext3). Voila: $>ll -R lib/modules/2.4.20-4GB-athlon/kernel/fs/ lib/modules/2.4.20-4GB-athlon/kernel/fs/: drwxr-xr-x 4 root root 1024 2003-06-19 18:58 . drwxr-xr-x 3 root root 1024 2003-06-19 18:58 .. drwxr-xr-x 2 root root 1024 2003-06-19 18:58 ext3 drwxr-xr-x 2 root root 1024 2003-06-19 18:58 jbd lib/modules/2.4.20-4GB-athlon/kernel/fs/ext3: drwxr-xr-x 2 root root 1024 2003-06-19 18:58 . drwxr-xr-x 4 root root 1024 2003-06-19 18:58 .. -rw-r--r-- 1 root root 116577 2003-06-18 10:27 ext3.o lib/modules/2.4.20-4GB-athlon/kernel/fs/jbd: drwxr-xr-x 2 root root 1024 2003-06-19 18:58 . drwxr-xr-x 4 root root 1024 2003-06-19 18:58 .. -rw-r--r-- 1 root root 78456 2003-06-18 10:27 jbd.o Nun klarer? CU, Thomson