Initrd Kernel

Gandalf

Gandalf

Mitglied
Hallo!

Ich habe ein Problem mit meinem neu compilierten 2.4.20er Kernel. Ich kompiliere wie folgt und es tritt der Fehler auf:

make menuconfig
make dep
make clean
make-kpkg --initrd kernel_image
dpkg -i ../kernel-image-2.4.20.deb
-> ...
-> setting up kernel-image-2.4.20...
-> Failing to create initrd image.
-> dpkg: error processing kernel-image-2.4.20 (--install):
-> subprocess post-installation script returned error exit status 2
-> Errors were encountered while processing:
-> kernel-image.2.4.20

Danach befindet sich ein neuer vmlinuz-2.4.20 Kernel im /boot.
Ich wollte trotz der Fehlermeldung den neuen Kernel ausprobieren, mit einem alten Initrd image...

Beim booten des neuen 2.4.20 Kernels, findet er leider kein gültiges Initrd image und bleibt wegen fehlender Module später stehen, da kein root fs gemountet werden kann... folgende Meldungen gibt er aus:

-> RAMDISK: Couldn't find valid RAM disk image starting at 0.
-> Freeing initrd memory: 942k freed

Dann bleibt er kurze Zeit danach mit dem typischen "Cannot mount root fs" Fehler stehen. Ich habe dem Kernel das gleiche Initrd image zugewiesen, wie meinem alten 2.4.18er, der mit diesem problemlos booten kann! (verwende lilo)

Wie kann ich dpkg fehlerfrei ausführen?
Wieso kann er mein altes Image nicht benutzen?

Danke.
 
Original geschrieben von Gandalf

make-kpkg --initrd kernel_image
dpkg -i ../kernel-image-2.4.20.deb
äh? was soll das?
installier doch den kernel manuell, dann hast keine probleme mit der initrd und anderen zeug. die braucht man im allgemeinen sowieso nicht!

cu
thorus
 
wie äh???

na schön, dann sag mir mal wie ich direkt aus den kernel quellen nen initrd tauglichen vmlinuz zauber, außerdem hast du wohl nicht richtig gelesen, denn wenn ich ohne initrd mein root fs mounten könnte würde ich das wohl tun, nicht war?

desweiteren hat er den kernel ja schon erstellt und in /boot kopiert, genauso wie die system.map und die config; fakt ist aber, daß eben jene von mir geposteten meldungen erscheinen...

ich bitte um passendere beiträge ;)

kleiner Nachtrag zum original post:
natürlich sollte die erste frage ganz am ende bedeuten, warum ich gerade eben NICHT dpkg fehlerfrei ausführen kann :)

cu
Gandalf
 
sorry, war in eile...
ich dachte, dass es nichts bringt extra ein deb-packet zu machen, aber egal...

da du mit lilo bootest musst du in der lilo.conf die initrd= zeile auskommentieren, damit er mal ohne initrd booted!
dann überprüfst du bitte mal, ob das root-device richtig eingestellt ist und ob dein filesystem im kernel statisch eingebaut ist!

übrigens: du kannst (natürlich) ein image einer anderen kernel-version nicht benutzen! da müsstest ein neues machen, aber man braucht ja überhaupt keines, also ist das eh egal!

cu
thorus
 
Hi,

es geht doch darum, daß ich den treiber für den HDD controler erstmal über das initrd image laden muß, bevor ich mein root fs überhaupt mounten kann. Das ist doch überhaupt erst der grund für mein problem...

ich MUSS ein initrd kernel benutzen....

cu
Gandalf
 
pack doch den treiber auch in den kernel!
is doch kein problem, oder?

cu
thorus
 
Original geschrieben von thorus
pack doch den treiber auch in den kernel!
is doch kein problem, oder?

cu
thorus

Hmmm....

also, ich glaube, wir sollten das Problem jetzt mal so richtig strukturiert angehen (*klugscheiss*)

1. Zuerst mal sollte dem armen Gandalf mal jemand erklären, wie man unter seinem Linux (welches übrhaupt?) den Kernel fehlerfrei kompiliert. Ich weiss es leider auch nicht, würde aber vermuten, dass man mit einem make bzImage nach dem make clean weiterkäme. (Das sollte bei allen Linuxen klappen)

2. Dass ein kaputter Kernel (ERROR beim make) nicht bootet ist eigentlich anzunehmen. Ebenso wahrscheinlich ist es, dass eine neuer Kernel nicht mit einem initrd funktioniert, das für einen anderen Kernel gemacht ist, oder?

3. Natürlich ist es möglich den HD-Controller-Treiber sowohl in den Kernel, als auch in die initrd einzubauen. Wie schon thorus bemerkte, muss man natürlich die initrd-Zeile in der lilo.conf (oderr menu.lst beim GRUB) auskommentieren, wenn der Treiber im Kernel ist.
Wenn der Treiber im initrd stecken soll muss das initrd mit mkinitrd neu gebaut werden. Das funktioniert bei den verschiedenen Distros ziemlich unterschiedlich. Ich kenn's nur von RedHat und Suse. Da machst du einfach mkinitrd ohne Parameter.

Aber wie geagt: Erst mal muss der Kernel sich fehlerfrei bauen lassen. Sonst hilft der ganze Rest nichts.

cu
tom
 
Original geschrieben von tomvomland
2. Dass ein kaputter Kernel (ERROR beim make) nicht bootet ist eigentlich anzunehmen. Ebenso wahrscheinlich ist es, dass eine neuer Kernel nicht mit einem initrd funktioniert, das für einen anderen Kernel gemacht ist, oder?
Anmerkung: dann gibt's aber auch kein bzImage, von welchen du booten kannst...

Original geschrieben von tomvomland
3. Natürlich ist es möglich den HD-Controller-Treiber sowohl in den Kernel, als auch in die initrd einzubauen. Wie schon thorus bemerkte, muss man natürlich die initrd-Zeile in der lilo.conf (oderr menu.lst beim GRUB) auskommentieren, wenn der Treiber im Kernel ist.
Wenn der Treiber im initrd stecken soll muss das initrd mit mkinitrd neu gebaut werden. Das funktioniert bei den verschiedenen Distros ziemlich unterschiedlich. Ich kenn's nur von RedHat und Suse. Da machst du einfach mkinitrd ohne Parameter.
Ich versteh einfach nicht, für was eine initrd wirklich gut sein soll! Nur ein kleines Image, von welchen der Kernel beim Booten Module laden kann und welches danach ungemountet wird.
Wenn ich ein Modul will, dann mach ich eins! Und "wichtige Module" kommen bei mir in den Kernel (z.B. ext3, ide oder sowas).

cu
thorus
 
Zuletzt bearbeitet:
Ok, thorus,

fragt sich natürlich, was bei dem Script, das Gandalf ausführt schiefläuft. Das heisst; gibts zu dem Zeitpunkt des Fehlers schon ein bzImage oder nicht.

Ich geb dir recht, was die Kernelmodule betrifft: Die kann man mit sicherheit in den Kernel einbinden, wenn man schon mal einen baut.
Wenn man aber auf so Spielereien, wie z.B. eine Splashscreen beim Booten, Wert legt, braucht man wohl ein initrd. Und natürlich auch dann, wenn man zu Bootzeit Module einbinden will, für die man nicht extra einen neuen Kernel bauen will.

cu
tom
 
Halli-hallo alle zusammen, also dann will ich mich nochmal erklären, damit auch jeder genau weiß, was denn nun das Problem ist ;)

Also...
*lufthol

ich habe da folgende Hardware:
Soyo Mainboard mit 'normalem' IDE Controller und einem IDE-Raid Controller, dem besagten HPT 372.
An den normalen Controller habe ich meinen Brenner (hda) und mein DVD Laufwerk (hdb) gekabelt.
An den HPT 372 habe ich meine beiden Platten angestöpselt.
Die 'sollten' demnach dann als hdc & hdd laufen, tun aber nach dem laden des (vom Herrsteller als Sourcen zur verfügung gestellten) Moduls Ihren Dienst aufgrund der SCSI Emulation (des Moduls) als sda & sdb.

Auf Seiten der Software:
Ich habe da Debian 3.0 mit einem 2.4.18er Initrd-Kernel, der mittels eines Initrd Images das Modul des HPT 372 Controllers lädt, damit er mein Root FS mounten kann.

Eigentlich läuft das System also, aber mit einigen Unannehmlichkeiten... die da wären, daß er unendlich lange zum booten braucht, weil dieser ganze IDE-Standart-Quatsch ewig lange rumsuchen und proben will, aber letztendlich nichts zu stande bringt; außerdem gefällt mir der Umweg über das Initrd Image eigentlich nicht...

Also will ich einen neuen Kernel installieren, nämlich den 2.4.20er.
Dazu habe ich mir von Kernel.org die Quellen gezogen und entsprechend entpackt.

Jetzt stehe ich natürlich vor der Wahl, einen neuen Initrd Kernel zu compilieren oder das Modul für den HPT 372 fest mit einzubinden und ohne Initrd Image auszukommen.

Der "Initrd Image"-Weg:
=======================

Ich versuche mit den folgenden Befehlen einen neuen Initrd Kernel zu erstellen & installieren:
> make menuconfig (benutze Standarteinstellungen + Ext3|CramFS|RAM disk support|initial RAM disk support)
> make dep
> make clean
> make-kpkg --initrd kernel_image
> dpkg -i ../'kernel-image-name'

Hier die Fehlermeldung, die er bei diesem Schritt ausgibt:

"Unpacking replacement kernel-image.2.4.20 ..."
"Setting up kernel-image-2.4.20 (10.00.Custom) ..."
"Failed to create initrd image."
"dpkg: error processing kernel-image-2.4.20 (--install):"
" subprocess post-installation script returned error exit status 2"
"Errors were encountered while processing:"
" kernel-image-2.4.20"

Er hat zu diesem Zeitpunkt bereits ein vmlinuz im /boot erstellt, daß ich auch booten kann... dann findet er aber aus mir unerfindlichen Gründen kein gültiges Initrd Image finden (ja, lilo ist richtig eingerichtet...)

es würden folgen:
> make modules
> make modules_install

Der "fest einbinden"-Weg:
=========================

Das ist der Weg, den ich am liebsten einschlagen würde...
Tja, wenn mir jemand sagen kann, wohin ich die Quellen des Moduls kopieren muß und wie ich dann das Modul mit in den Kernel compilieren kann... ich hab keine Ahnung :(


OK, das sollte erstmal reichen denke ich...
Ich danke euch allen euch so rege zu beteiligen! :)

Gandalf
 
Hi Gandalf,
wenn ich das Readme zu Ver. 1.3 des Treibers richtig verstehe, gibt es keine Möglichkeit das Modul direkt in den Kernel einzbauen.
Wie bei den meisten Modulen von Drittanbietern, baust Du das Modul lediglich unter Angabe des Pfades zu den Kernelsourcen. (depmod -a nicht vergessen ;) )

Ich würde also jetzt den Kernel Konfiguieren (am besten scsi_mod und sd_mod fest einbauen, wie im Readme empfohlen)

dann:
make dep
make clean
make bzImage
make modules
make modules_install
(kennst Du ja...)

So, wenn das jetzt ein RedHat-System wäre, wüsste ich genau, was Du als nächstes machen musst. Da Du jedoch Debian benutzt, kann ich nur hoffen, das das da genauso geht:

Du bindest das Module für den HPT 372
in die /etc/modules.conf ein und führst danach mkinitrd aus, um das initrd mit dem Treiber zu erstellen. (Bei RedHat werden automatisch alle Module aus der modules.conf in das initrd eingebaut)
Wie das dann mit dem lilo geht, weisst Du ja.

Mit Debian hast Du natürlich verloren, wenn das Modul speziell für die gepatchten Kernels der supporteten Distributionen (SuSE, Redhat, Caldera, Turbo) geschreiben wurde.

*stop

Hast Du am Ende nur vergessen, die Module sd und scsi in den Kernel (oder initrd) einzubinden??

cu
tom
 
Hi-Ho

Also ich habe jetzt nochmals getestet und mit dem 2.4.18er Kernel klappt alles wunderbar (kompilieren & mit initrd booten), aber wenn ich das gleiche mit dem 2.4.20er versuche, findet er beim booten kein gültiges initrd image... "cannot find valid initrd image starting at block 0"...

ich gebe das gleiche initrd image wie beim 2.4.18er kernel an, ich benutze auch die für den initrd start notwendigen konfigurationen über make menuconfig....

Aus meiner Sicht müsste er doch wenigstens versuchen, mit dem initrd image irgendwas anufangen, wenngleich er nicht unbedingt die im image befindlichen 2.4.18er Module laden können müsste...

Um die scsi_mod & sd_mod mit einzubinden, habe ich die SCSI Emulation im Menü als fest eincompilieren eingestellt, ist das ausreichend?

Also so langsam bin ich am verzweifeln...

Das wars dann erstmal wieder von mir,
euch allen frohe Weihnachten!
Gandalf
 
hi!
er sagt ja "cannot find valid initrd image starting at block 0". du kannst auch nicht ohne weiteres module von einem kernel in einen anderen tun, aber wenn ich mich recht erinnere hab ich mal mit insmod -f sowas gemacht.. aber egal.
du musst auf jeden fall für deinen kernel eine angepasste initrd machen, vor allem wenn es sich um 2 verschiedene kernel-versionen handelt.

cu
thorus
 
Moin,

ist nur die Frage ob er gleich meckert weil es eigentlich Module vom 2.4.18er enthält oder ob er das nicht erst merken könnte wenn diese (nach dem laden des initrd images in den Speicher) in den kernel geladen werden sollen... nur findet ein laden des images in den Speicher niemals statt...

...Rätsel in der Finsternis (des Bootvorgangs)...

cu
 
Hi,

also da ich jetzt wirklich lange genug rumprobiert habe, wede ich jetzt beim 2.4.18er bleiben :( Hab einfach die Nase voll davon....

Dank an die, die sich so rege beteiligt haben,

cu
Gandalf
 

Ähnliche Themen

wie Alte Kernelversionen unter Debian entfernen

Kernel Panic GRUB 2

Debian Kernel kompilieren

Kernel 3 Kompilierungsproblem unter XEN

E: Sub-process /usr/bin/dpkg returned an error code (1)

Zurück
Oben