initrd mit HPT-Modul

[klaus_h]

Die initrd wurde unter einem kernel 2.4.20 für den 2.6.11.6 erstellt,
der Aufruf von mkinitrd (0.1.81.1) erfolgte mit:

mkinitrd -k -o /usr/src/initrd/initrd.testing.img 2.6.11.6

Das Image bleibt in /tmp erhalten, deswegen läßt sich auch feststellen,
daß das Modul hpt37x2.ko im Image vorhanden ist.

Fehlermeldung beim Erstellen des Images:

/usr/sbin/mkinitrd: The working directory /tmp/mkinitrd.pwRWMc will be kept.
/usr/sbin/mkinitrd: add_modules_dep_2_5: modprobe failed
FATAL: Module hpt37x2.ko not found.
WARNING: This failure MAY indicate that your kernel will not boot!
but it can also be triggered by needed modules being compiled into
the kernel.

Fehlermeldung beim Booten dieses Images:

initrd-tools: 0.1.81.1
FATAL: Module hpt37x2.ko not found

System: Debian sarge

Die Konfiguration:
Kernelsource: 2.6.11.6
Der Kernel hat alle SCSI-Treiber fest eingebaut.
mkcramfs ist installiert, der laufende kernel kann dies aber nicht lesen,
da nicht einkompiliert.

HPT-Treiber: v2.0 10Nov2004 support for kernel 2.6.x
Das Modul wurde erfolgreich gegen den Kernel kompiliert
(es erschienen allerdings einige Warnings)

/etc/mkinitrd/mkinitrd.conf

# What modules to install.
MODULES=all
# The length (in seconds) of the startup delay during which linuxrc may be
# interrupted.
DELAY=0
# If this is set to probe mkinitrd will try to figure out what's needed to
# mount the root file system. This is equivalent to the old PROBE=on setting.
# ROOT=probe
ROOT=
# This controls the permission of the resulting initrd image.
UMASK=022
# Command to generate the initrd image.
# %s=path_to_image_directory %s=output_filename
MKIMAGE='mkcramfs %s %s > /dev/null'
# Set this to yes if you want to use busybox(1).
BUSYBOX=no
# Set this to no if you want to disable /usr/share/initrd-tools/scripts.
PKGSCRIPTS=yes
# This is the value for LD_LIBRARY_PATH when deciding what goes onto the
# image.
INITRD_LD_LIBRARY_PATH=$LD_LIBRARY_PATH
# Hardcode partition to resume from so it doesn't have to be specified
# on the command line. The command line will override this setting.
# RESUME=

/etc/mkinitrd/modules

# This file should contain the names of kernel modules and their arguments
# (if any) that are needed to mount the root file system, one per line.
# Comments begin with a `#', and everything on the line after them are ignored.
#
hpt37x2

Hat jemand eine Idee, wo er dieses Modul sucht?
Liegt es an LD_LIBRARY_PATH (die gibts bei mir scheinbar nicht)?

[gms]

was ergibt denn

Code: Alles auswählen

grep hpt37x2.ko: /lib/modules/2.6.11.6/modules.dep

Damit sollten alle Module ausgegeben werden, von denen hpt37x2 abhängt. Diese dann zusätzlich in die Datei /etc/mkinitrd/modules eintragen und die initrrd neu erstellen.
Ich hoffe das hilft

Gruß
gms

[klaus_h]

Vielen Dank für Deine Antwort,

der angegebene grep-String hat einen leeren Output.
Das wohl, weil die benötigten SCSI-Module fest im kernel sitzen.
Sollte man vielleicht mal das sg als Modul einbinden?

Ich habe das grep mit allen 3 kernel ausprobiert, die ich
mittlerweile zum Testen installiert habe, zusätzlich
habe ich gestern noch den 2.6.8 aus der debian-distri
installiert, bringt aber den gleichen Effekt.

[KBDCALLS]

Solange das nur Warnings sind soll dich das nicht kratzen. Hast du cramfs im Kernel? Also nicht als Modul! Ansonsten fällt Debian auf die Nase beim Laden der Initrd. Und gibt es das Modul denn wirklich ? Such es mal mit .locate

[gms]

Sollte man vielleicht mal das sg als Modul einbinden?

Ich würde eher versuchen die initrd los zu werden, dh. alles was du zum Booten benötigst fix in den Kernel einbinden.

Das der Debian-Standardkernel auch nicht funkt, ist aber verdächtig. Kommt da auch die gleiche Fehlermeldung ?
Warum du mkinitrd mit "-o /usr/src/initrd/initrd.testing.img" aufrufst ist mir auch nicht ganz klar.

Gruß
gms

[KBDCALLS]

Das ist auch in der Tat komisch der Aufruf. Denn die Initrds müssen in dem Verzeichnis sein, wo auch die die Kernels sind. Also im Boot.

Code: Alles auswählen

 mkinitrd -o /boot/initrd.img-2.6.12-0-k7 2.6.12-0-k7

Zum Beispiel. Und wenn du ihm nicht sagst welchse Vereichnis er nehmen soll, Erstellst du eine Initrd die die Module für einen 2.4 Kernel beinhaltet. Und das funzt nun wiklich nicht mit einem Kernel 2.6.xx

Außerdem brauchst du die module-init-tools

https://knecht.homelinux.net/phpBB2/viewtopic.php?t=481

[klaus_h]

Vielen Dank für Eure Beiträge,

hier noch ein paar Erläuterungen:
Ich erstelle die initrd in einem anderen Ordner als boot und kopiere sie dann hinein,
der komplette Erstellungsvorgang der initrd sieht dann so aus, z.B. für den debian 2.6.8:

Code: Alles auswählen

cd /usr/src/initrd
mkinitrd -k -o /usr/src/initrd/initrd.testing.img 2.6.8
gzip -cf initrd.testing.img >initrd.testing
mount /dev/sda1 /boot
cp initrd.testing /boot/initrd-2.6.8
lilo

Das Image bleibt dann in /tmp/mkinitrd.XXXXX erhalten.

Ich wüßte übrigens nicht, wie ich das HPT-Modul in den kernel kriege...

cramfs ist im (neuen) kernel eingebaut, ich bin grade dabei, es auch im alten 2.4.20
zu aktivieren, dann kann ich die fertige initrd auch unter 2.4.20 mounten.

module-init-tools 3.2-pre1-2 sind installiert.

[KBDCALLS]

Wenns ein Kernel von Kernel.org ist dann vergiß initrd mit cramfs und Kernel 2.4 Siehe Link.


Hast du denn mal nach dem Modul mit locate gesucht. Und hast du dir die Initrd mal von Innen angesehen?

[klaus_h]

Das cramfs unter dem 2.4.20 dient nur dazu, die initrd für
den 2.6.x zu mounten, damit man wirklich sieht, was im
image drin ist.
Das hat aber leider nicht funktioniert, deswegen muß ich mich
darauf verlassen, was im tmp-Verzeichnis von mkinitrd angelegt wurde.
Dort ist auf jeden Fall das Modul vorhanden:

Code: Alles auswählen

/tmp/mkinitrd.G1PEOM/initrd/lib/modules/2.6.8/kernel/drivers/scsi/hpt37x2.ko

Dies ist der Inhalt von /tmp/mkinitrd.G1PEOM/initrd/loadmodules

Code: Alles auswählen

modprobe -k  hpt37x2.ko
modprobe -k  unix 2> /dev/null
modprobe -k hpt37x2.ko

(warum zweimal?)

[KBDCALLS]

Das funktioniert schon du mußt über das Loopdevice gehen.

Code: Alles auswählen

mount -o loop -t cramfs /boot/initrd.img-usw. /mnt 

Ein Intrd mounten ist nix anderes als ein ISO-Image einer CD/DVD wenn man mal vom Dateisystem absieht.

Das sagt garnix

Code: Alles auswählen

Dies ist der Inhalt von /tmp/mkinitrd.G1PEOM/initrd/loadmodules
Code:
modprobe -k  hpt37x2.ko
modprobe -k  unix 2> /dev/null
modprobe -k hpt37x2.ko

Deswegen muß das Modul trotzdem nicht in der Iintrd sein. Intessannt ist erstmal was ist im /lib/modules/kernelversion

[klaus_h]

ok, mounten geht jetzt mit:

Code: Alles auswählen

mount -o loop -t cramfs /usr/src/initrd/initrd.testing.img /mnt

unter dem laufenden 2.4.20

Das Modul ist in der gemounteten initrd vorhanden.
weiß nicht was Du mit

/lib/modules/kernelversion

meinst, eine Datei dazu gibt es nicht im Image.

[KBDCALLS]

Auf denem Recher gibt es ein Verzeichnis

Code: Alles auswählen

/lib/modules/2.6.11.6

und das muß es auch in der Initrd geben.

Ich habe zwar jetzt einen anderen Kernel

Dieses Vereichnis ist auf der Festplatte meines Rechners.

Code: Alles auswählen

/lib/modules/2.6.12-0-k7/

Code: Alles auswählen

/mnt/lib/modules/2.6.12-0-k7/

und das hier in der Initrd. Die vorher nach /mnt gemountet habe.

[klaus_h]

Genau so isses auch!
Da ich gerade den 2.6.8 (debian) ausprobiere,
ist in der initrd das Verzeichnis
/lib/modules/2.6.8/kernel/derivers/scsi
mit dem fraglichen Modul.
Kanns sein daß er den Pfad nicht findet?

[KBDCALLS]

Jetzt ist eigentlich nur noch die Frage zu klären ob das Modul auch wirklich in der Inirtrd enthalten. Denn die Auflistung in der loadmodules reicht nicht immer. Manchmal muß man dem mkinitrd klar machen das es dieses oder jenes Modul mitreinpacken soll. Eigentlich sollten die Module immer gefunden werden. Einzige Bedingung ist das sie innerhalb des entsprechenden Unterverzeichniss liegen.

[klaus_h]

Wie gesagt, in der gemounteten initrd ist es vorhanden...

Übrigens kann ich die initrd nur readonly mounten, auch mit:

Code: Alles auswählen

mount -o loop,rw -t cramfs /usr/src/initrd/initrd.testing.img /mnt

kann ich nichts verändern.
Dann könnte man nämlich ein paar debug-Ausgaben ins linuxrc einbauen,
z.b. ein ls -l nach dem Modul.

Liegt das am cramfs?

[klaus_h]

Ich habe jetzt mal im mkinitrd-Script nachgeschaut, wo der Fehler auftritt,
wenn man die Parameter ersetzt, wird folgendes aufgerufen:

Code: Alles auswählen

modprobe --set-version '2.6.8' --show-depends hpt37x2

das ergibt dann:

FATAL: Module hpt37x2 not found

(das .ko habe ich weggelassen siehe unten)
Das Modul ist definitiv da!

wenn ich dasselbe für den alten kernel ausführe:

Code: Alles auswählen

modprobe --set-version '2.4.20' --show-depends hpt37x2

erhalte ich:

insmod /lib/modules/2.4.20/kernel/drivers/scsi/hpt37x2.o

(das Modul muß ohne .o angegeben werden)

Ich habe ausserdem die Erstellungsvariablen von mkinitrd in Bezug auf
Kernelversion überprüft (mit Hilfe von /etc/mkinitrd/script), das paßt auch alles.

Hängt irgendwie mit dem modprobe zusammen...

[KBDCALLS]

Versuch mal folgendes

Code: Alles auswählen

depmod -ae -F Sytem.map 2.6.12.3

Natrürlich die richtige Kernelversion einsetzen.

[klaus_h]

Code: Alles auswählen

depmod -ae -F System.map 2.4.20

Code: Alles auswählen

depmod -ae -F System.map 2.6.8

Code: Alles auswählen

depmod -ae -F System.map 2.6.11.6

ergibt keine Rückgabe,
man muß natürlich dazu im jeweiligen source-tree stehen.

[klaus_h]

Ich habe jetzt noch mal zwei initrd erstellt für
2.6.8. und 2.6.11.6 und nach dem nächsten Neustart ging es dann,
und zwar mit beiden Versionen!

Nach dem Aufruf von

Code: Alles auswählen

depmod -ae -F System.map 2.6.11.6

ist alles in Butter!

Vielen Dank allen, die mir geholfen haben.

[minimike]

ja cramfs ist ein "Read onley" Dateisystem, mkinitrd hat mir schlaflose Nächte bereitet, angefangen damit das in der Doku sachen drinn standen die in der Praxis nicht funktionierten bis hin zu 45 MB grossen intrd's.Schau dir mal Gentoo' genkernel an die benutzen ext2 und Busybox. Ist genial hat funktionierende Mailinglisten die Doku ist prima und läft hier bestens mit meinem Debian

[KBDCALLS]

Das funktioniert schon, nur man muß dem dem Kernel beim Kompieleren mitteilen das man so ein Riesending benutzen will. Normalerweise ist der Standard für i386 System 8192 kb. Debian hat den schon raufgesetzt auf 16384 kb Ich kann aber ohne Problem höher gehen.

[klaus_h]

Ja wie gesagt, jetzt funktioniert wieder alles,
und ich persönlich gehe immer möglichst debian-konform,
d.h. mit Paketen aus der Distri, von einigen Ausnahmen wie kernel-sourcen mal abgesehen...
Vielen Dank noch mal!