Kernel auf einem anderen Rechner bauen und kompilieren
Hallo miteinander, Ich habe Probleme mit meiner SCSI AHA1542, beim Booten bricht Linux mit Kernelpanik ab: kmod: failed to exec /sbin/modprobe -s -k block-major-8, errno = 2 Kernel panic: VFS: Unable to mount root fs on 08:07 Wenn ich den Kernel mit den Installationsdisketten starte, dann klappt alles. Ich vermute der Treiber macht Schwierigkeiten, wenn er als Modul geladen werden soll. Deshalb habe ich jetzt vor den AHA1542 in den Kernel einzu- kompilieren. Der Rechner ist ein alter 486, also ziemlich langsam. Als Internetgateway für mein Netzwerk aber tut er es bestimmt. Jetzt zu meiner Frage: Was muß ich beachten, wenn ich einen Kernel auf einem anderen System baue und kompiliere. Was muß ich bei den Modulen beachten. Danke, Andreas Rathgeber __________________________________________________________________ Do You Yahoo!? Gesendet von Yahoo! Mail - http://mail.yahoo.de Yahoo! Auktionen - gleich ausprobieren - http://auktionen.yahoo.de --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
On Tue, 4 Jul 2000, Andreas Rathgeber wrote:
Ich habe Probleme mit meiner SCSI AHA1542, beim Booten bricht Linux mit Kernelpanik ab: kmod: failed to exec /sbin/modprobe -s -k block-major-8, errno = 2 Kernel panic: VFS: Unable to mount root fs on 08:07
Die Problematik ist recht einfach: Ein Filesystem, von welchem auch das System gebootet werden soll, darf nicht als Modul geladen werden, denn das Laden der Module setzt ein bereits bestehendes Dateisystem voraus. Fazit: Der Kernel muss auf einem Dateisystem liegen, welches fest einkompiliert wurde, also kreuze hier einmal das "Module" aus und setze den Parameter fest in den Kernel hinein.
Wenn ich den Kernel mit den Installationsdisketten starte, dann klappt alles.
Klar! Denn dort sitzt es im Kernel fest drin und erlaubt dann das Booten ueber das angesprochene Device.
Ich vermute der Treiber macht Schwierigkeiten, wenn er als Modul geladen werden soll.
Sic!
Deshalb habe ich jetzt vor den AHA1542 in den Kernel einzu- kompilieren.
Es wird nicht anders gehen.
Der Rechner ist ein alter 486,
Das ist keinesfalls alt. Das ist genauso gebrauchsfeaehig wie alles andere auch. Ich habe hier noch Server bei Kunden laufen, die einen 386-40 haben. Natuerlich dauert das Kompilieren eines neuen Kernels dort ohne weiteres ein bis anderthalb Tage, doch: Was soll's?
Als Internetgateway für mein Netzwerk aber tut er es bestimmt.
Ueberhaupt kein Problem. Squid drauf und vielleicht so um die 16 MB RAM und die Sache ist voellig in Ordnung.
Was muß ich beachten, wenn ich einen Kernel auf einem anderen System baue und kompiliere. Was muß ich bei den Modulen beachten.
Eigentlich gar nichts. Baue den Kernel ruhig zusammen. Das ergibt ein entsprechendes Image, das wird Dir am Ende des Kompilates angezeigt, das kannst Du auf den Zielrechner kopieren. Und die Module? In solchen Faellen habe ich die - geringe - Nacharbeit der Module immer auf dem Zielsystem selber durchgefuehrt. Das mag ein bisschen dauern. Doch: Eine kleine Kaffeepause befreit die Denkerstirn. Gruss Peter Blancke -- Nachtwaechter ist der Wahnsinn, weil er wacht... --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Peter Blancke wrote:
On Tue, 4 Jul 2000, Andreas Rathgeber wrote:
Ich habe Probleme mit meiner SCSI AHA1542, beim Booten bricht Linux mit Kernelpanik ab: kmod: failed to exec /sbin/modprobe -s -k block-major-8, errno = 2 Kernel panic: VFS: Unable to mount root fs on 08:07
Die Problematik ist recht einfach: Ein Filesystem, von welchem auch das System gebootet werden soll, darf nicht als Modul geladen werden, denn das Laden der Module setzt ein bereits bestehendes Dateisystem voraus. Fazit: Der Kernel muss auf einem Dateisystem liegen, welches fest einkompiliert wurde, also kreuze hier einmal das "Module" aus und setze den Parameter fest in den Kernel hinein.
Eigentlich hatte ich gedacht Suse 6.3 besitzt ein neues Bootkonzept, daß so etwas unötig macht. siehe: http://sdb.suse.de/sdb/de/html/adrian_6.3_boot.html Zitat aus selbem: Der LILO wird vom BIOS gestartet (ähnlicher Ablauf, wenn Sie loadlin verwenden). LILO lädt mit Hilfe des BIOS die initrd (die Ramdisk) in den Speicher. LILO lädt ebenfalls mit Hilfe des BIOS den Kernel in den Speicher, übergibt nötige Parameter und startet den Kernel. Der Kernel initialisiert sich und mountet als Root-Dateiystem die Ramdisk. Aus der Ramdisk werden die nötigen Kernelmodule (meist SCSI-Module) geladen. Nun wird das Root-Dateisystem vom Kernel neu gemountet und das tatsächliche Root-Dateisystem von der Festplatte gemountet, sowie der init-Prozess gestartet. Bootkonzept hin oder her. Der Kernel wird kompiliert (Punkt) Danke, Andreas Rathgeber __________________________________________________________________ Do You Yahoo!? Gesendet von Yahoo! Mail - http://mail.yahoo.de Yahoo! Auktionen - gleich ausprobieren - http://auktionen.yahoo.de --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Am Die, 04 Jul 2000 schrieb Andreas Rathgeber:
Was muß ich beachten, wenn ich einen Kernel auf einem anderen System baue und kompiliere. Was muß ich bei den Modulen beachten.
Natürlich solltest Du den entsprechenden Prozessor einstellen und alles was sonst auf der Kiste benötigt wird, dann sollte es (wenn beides x86er sind, wenn der schnelle ein PPC, SPARC, Alpha, ... ist, wirds komplizierter) eigentlich keine Probleme geben. Ich würd "make dep clean bzImage modules" auf der schnellen Kiste durchführen, /usr/src/linux dann auf den 486er rüberkopieren und dort ein "make modules_install bzlilo" hinterherjagen. Letzteres braucht kaum Zeit (compiliert ist ja alles) und die Installation wird trotzdem auf dem richtigen Rechner durchgeführt. -- Machs gut | http://www.iiv.de/schwinde/buerger/tremmel/ | http://www.knightsoft.de Manfred | http://www.knightsoft-net.de --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Andreas Rathgeber wrote:
Hallo miteinander,
Ich habe Probleme mit meiner SCSI AHA1542, beim Booten bricht Linux mit Kernelpanik ab: kmod: failed to exec /sbin/modprobe -s -k block-major-8, errno = 2 Kernel panic: VFS: Unable to mount root fs on 08:07
Wenn ich den Kernel mit den Installationsdisketten starte, dann klappt alles. Ich vermute der Treiber macht Schwierigkeiten, wenn er als Modul geladen werden soll.
Deshalb habe ich jetzt vor den AHA1542 in den Kernel einzu- kompilieren. Der Rechner ist ein alter 486, also ziemlich langsam. Als Internetgateway für mein Netzwerk aber tut er es bestimmt.
Jetzt zu meiner Frage: Was muß ich beachten, wenn ich einen Kernel auf einem anderen System baue und kompiliere. Was muß ich bei den Modulen beachten.
Danke,
Andreas Rathgeber
Die Lösung und die funktionierte so: Es gab wohl Probleme bei den Parametern der Module, die bei der Installation nicht mit in die initrd übergeben wurden. 1. sichern der /boot/initrd 2. entpacken der /boot/initrd nach /tmp/initrd mit: zcat /boot/initrd > /tmp/initrd 3. mounten dieser initial ram disk nach /mnt: mount -t ext2 -o loop /tmp/initrd /mnt 4. editieren von linuxrc nach den Beispielen: insmod aha1542 aha1542=0x130,11 insmod ni65 dma=7 5. Verzeichnis unmounten /mnt 6. packen von /tmp/initrd mit gzip, eventuell umbenennen nach /tmp/initrd 7. zurückkopieren von /tmp/initrd nach /boot/initrd 8. in /etc/lilo.conf muß auch diese Zeile stehen initrd=/boot/initrd 9. lilo ausführen 10. reboot tut gut ;-) das höre ich immer von meinen Windows NT-Kollegen Nach ca. 40 Stunden an verschieden Möglichkeiten habe ich das System so zum laufen gebracht. Wahrscheinlich wäre es schneller gewesen den Kernel mit SCSI-Untestüzung zu kompilieren, aber dieser Weg ist viel eleganter. Tschüß, Andreas Rathgeber __________________________________________________________________ Do You Yahoo!? Gesendet von Yahoo! Mail - http://mail.yahoo.de Yahoo! Auktionen - gleich ausprobieren - http://auktionen.yahoo.de --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
On Thu, Jul 06, 2000, Andreas Rathgeber wrote:
Die Lösung und die funktionierte so:
Es gab wohl Probleme bei den Parametern der Module, die bei der Installation nicht mit in die initrd übergeben wurden. 1. sichern der /boot/initrd 2. entpacken der /boot/initrd nach /tmp/initrd mit: zcat /boot/initrd > /tmp/initrd 3. mounten dieser initial ram disk nach /mnt: mount -t ext2 -o loop /tmp/initrd /mnt 4. editieren von linuxrc nach den Beispielen: insmod aha1542 aha1542=0x130,11 insmod ni65 dma=7 5. Verzeichnis unmounten /mnt 6. packen von /tmp/initrd mit gzip, eventuell umbenennen nach /tmp/initrd 7. zurückkopieren von /tmp/initrd nach /boot/initrd 8. in /etc/lilo.conf muß auch diese Zeile stehen initrd=/boot/initrd 9. lilo ausführen 10. reboot tut gut ;-) das höre ich immer von meinen Windows NT-Kollegen
Ja, so geht es sicherlich. Es gibt aber auch ein script mk_initrd von SuSE, welches eine initrd selbsttätig erstellt. (Alte initrd vorher besser sichern.) Dazu liest es die Datei /etc/rc.config ein und wertet die Einträge aus, welche Module geladen werden sollen. (INITRD?) (Diese|Die zum Zugriff auf Platten benötigten) Module werden dann in die initrd eingebaut. MfG Gunther -- Dipl.-Ing. Gunther Kuhlmann Gunther_Kuhlmann@mentorg.com Tel.: +44 (0)12 52 / 74 83 25 PGP: E6 BC 78 6B E6 09 C7 16 AB 5D 9A 9A D7 1C 01 FB -- --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Gunther Kuhlmann schrieb:
On Thu, Jul 06, 2000, Andreas Rathgeber wrote:
Die Lösung und die funktionierte so:
Es gab wohl Probleme bei den Parametern der Module, die bei der Installation nicht mit in die initrd übergeben wurden. 1. sichern der /boot/initrd 2. entpacken der /boot/initrd nach /tmp/initrd mit: zcat /boot/initrd > /tmp/initrd 3. mounten dieser initial ram disk nach /mnt: mount -t ext2 -o loop /tmp/initrd /mnt 4. editieren von linuxrc nach den Beispielen: insmod aha1542 aha1542=0x130,11 insmod ni65 dma=7 5. Verzeichnis unmounten /mnt 6. packen von /tmp/initrd mit gzip, eventuell umbenennen nach /tmp/initrd 7. zurückkopieren von /tmp/initrd nach /boot/initrd 8. in /etc/lilo.conf muß auch diese Zeile stehen initrd=/boot/initrd 9. lilo ausführen 10. reboot tut gut ;-) das höre ich immer von meinen Windows NT-Kollegen
Ja, so geht es sicherlich. Es gibt aber auch ein script mk_initrd von SuSE, welches eine initrd selbsttätig erstellt. (Alte initrd vorher besser sichern.) Dazu liest es die Datei /etc/rc.config ein und wertet die Einträge aus, welche Module geladen werden sollen. (INITRD?) (Diese|Die zum Zugriff auf Platten benötigten) Module werden dann in die initrd eingebaut.
Prinzipiell ist das richtig, zumindest ab Suse 6.4. Ich verwende jedoch 6.3 und da funktioniert es nur so, wie oben beschrieben. Auszug aus der SuSE Support-Datenbank: http://sdb.suse.de/sdb/de/html/initrd.html ... Modulparameter Ist für das Laden eines bestimmten Modules die Angabe von Parametern notwendig, dann gehen diese nach der Installation verloren; sie werden nicht in die für das Booten des Systems verwendete initrd eingetragen. Glücklicherweise gibt es nur sehr wenige SCSI-Treiber, die zwingend die Angabe von Parametern erfordern. Wer auf das Problem stösst, muss sein System mit der Installations-Bootdiskette booten und sich einen Kernel bauen, der den SCSI-Treiber enthält. Das Problem ist inzwischen behoben, bei SuSE 6.4 werden etwaige Modulparameter auch beim Starten des Systems in der initrd verwendet. ... Sorry, daß ich vom Subject abgekommen bin, aber ich war von dieser eleganten Lösung so angetan. Auf die bin ich übrigens von einem Kollegen hingewiesen worden. Gruß Andreas Rathgeber __________________________________________________________________ Do You Yahoo!? Gesendet von Yahoo! Mail - http://mail.yahoo.de Yahoo! Auktionen - gleich ausprobieren - http://auktionen.yahoo.de --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
participants (4)
-
blancke＠gmx.de -
gunther_kuhlmann＠mentorg.com -
Manfred.Tremmel＠iiv.de -
rathgeber2000＠yahoo.de