meine erste initrd: keine USB-Tastatur

[cosmac]

hi,

Ich hätte gern direkt am Anfang von /etc/init.d/rcS schon eine USB-Tastatur. Die Module hid, usbhid und evdev hab' ich schon in /etc/initramfs-tools/modules eingetragen und die initrd neu gebaut, aber das hilft nichts. Gibt es eine offizielle Methode, einzelne Module früher zu laden?

Ich hab' auch versucht, per "dpkg-reconfigure linux-image-x.y.z" eine initrd "mit allem" zu bekommen, aber die Option gibt's anscheinend nur während der Installation und da hab' ich die platzsparende gewählt.

Alternativ könnte
- udev mit einem selbstgebauten Kernel ohne initrd funktionieren
- der xserver wie früher mit xorg.conf statt udev auskommen
- der xserver mit manuell erzeugten Links unter /dev/input funktionieren
alle Möglichkeiten scheinen mir ähnlich aussichtslos

[rendegast]

Die Module hid, usbhid und evdev hab' ich schon in /etc/initramfs-tools/modules eingetragen

Eventuell fehlen noch einige, da der Mechanismus vielleicht keine Abhängigkeiten berücksichtigt?
ZBsp usbcore? und usbcore braucht nls_base ...

Code: Alles auswählen

$ lsmod | grep usb
usb_storage            30397  0 
usbcore               100226  4 usb_storage,ohci_hcd,ehci_hcd
nls_base                4541  6 cifs,nls_utf8,nls_cp437,vfat,fat,usbcore
scsi_mod              101733  3 usb_storage,sd_mod,libata

Die erstellte initrd kann durchsucht werden, umbenannt als initrd.cpio oder initrd.cpio.gz.

MODULES=most bringt auch nur ein beschränktes Repertoir:

$ find -type f
./2.6.32-3-686-bigmem/kernel/arch/x86/kernel/cpuid.ko
./2.6.32-3-686-bigmem/kernel/arch/x86/kernel/msr.ko
./2.6.32-3-686-bigmem/kernel/fs/mbcache.ko
./2.6.32-3-686-bigmem/kernel/fs/jbd/jbd.ko
./2.6.32-3-686-bigmem/kernel/fs/ext3/ext3.ko
./2.6.32-3-686-bigmem/kernel/drivers/ide/ide-core.ko
./2.6.32-3-686-bigmem/kernel/drivers/ide/atiixp.ko
./2.6.32-3-686-bigmem/kernel/drivers/ide/ide-pci-generic.ko
./2.6.32-3-686-bigmem/kernel/drivers/ide/ide-gd_mod.ko
./2.6.32-3-686-bigmem/kernel/drivers/ide/ide-cd_mod.ko
./2.6.32-3-686-bigmem/kernel/drivers/scsi/scsi_mod.ko
./2.6.32-3-686-bigmem/kernel/drivers/scsi/sd_mod.ko
./2.6.32-3-686-bigmem/kernel/drivers/ata/libata.ko
./2.6.32-3-686-bigmem/kernel/drivers/ata/ata_generic.ko
./2.6.32-3-686-bigmem/kernel/drivers/cdrom/cdrom.ko
./2.6.32-3-686-bigmem/kernel/drivers/video/vgastate.ko
./2.6.32-3-686-bigmem/kernel/drivers/video/vga16fb.ko
./2.6.32-3-686-bigmem/kernel/drivers/thermal/thermal_sys.ko
./2.6.32-3-686-bigmem/kernel/drivers/acpi/fan.ko
./2.6.32-3-686-bigmem/kernel/drivers/acpi/thermal.ko
./2.6.32-3-686-bigmem/kernel/lib/crc-t10dif.ko

cpuid und msr kommen über /etc/initramfs-tools/modules, und haben beide keine weiteren Abhängigkeiten.
EDIT:
- Sorry, hier galt nicht 'MODULES=most', sondern 'MODULES=dep' aus einer (selbst angelegten) Datei in /etc/initramfs-tools/conf.d/.



----------------------------

Eventuell fehlen noch einige, da der Mechanismus vielleicht keine Abhängigkeiten berücksichtigt?

Yepp,
die Funktionen add_modules_from_file und force_load
(/usr/share/initramfs-tools/hook-funktions (aufgerufen durch update-initramfs -> mkinitramfs))
transportieren nur die aufgeführten Module in die initrd,
auf eventuelle Abhängigkeiten mußt Du dann selber achten.

[cosmac]

Eventuell fehlen noch einige, da der Mechanismus vielleicht keine Abhängigkeiten berücksichtigt?
ZBsp usbcore? und usbcore braucht nls_base ...

danke für den Tipp, ich bin ja von modprobe verwöhnt. Die Reihenfolge könnte dann auch noch wichtig sein, also hab' ich es mit insmod ausprobiert und das Ergebnis in modules geschrieben

Code: Alles auswählen

nls_base
usbcore
ohci_hcd
hid
usbhid

Aber es nützt nichts, der ganze USB-Kram wird erst später initialisiert. Da fehlt anscheinend noch was ganz anderes.

In der Tat: man muss die initrd nach *jeder* Änderung neu bauen und die /boot-Partition darf nicht readonly gemountet sein (oder man sollte wenigstens die Fehlermeldung lesen) und man muss *jedesmal* neu booten -- schon geht's
Vielen Dank nochmal!

Da die "große" initrd wohl auch nichts bringt, muss ich wohl meine Abfrage später als in rcS einbauen, aber das geht ja dank insserv & Co auch nicht mehr wie gewohnt *grml*.

[rendegast]

Prima,

Die Reihenfolge könnte dann auch noch wichtig sein,

Nein, in der initrd wird mit 'modprobe' gearbeitet, siehe
/init + /scripts/*, insbesondere dies in /scripts/functions :

Code: Alles auswählen

# Load custom modules first
load_modules()
{
	if [ -e /conf/modules ]; then
		cat /conf/modules | while read m; do
			# Skip empty lines
			if [ -z "$m" ];  then
				continue
			fi
			# Skip comments - d?ash removes whitespace prefix
			com=$(printf "%.1s" "${m}")
			if [ "$com" = "#" ]; then
				continue
			fi
			modprobe $m
		done
	fi
}

/conf/modules enthält unter anderem die Einträge aus /etc/initramfs-tools/modules.
Wenn das Hauptmodul zuerst genannt ist, werden also beim ersten Aufruf schon alle abhängigen Module mitgeladen.

MODULES=most bringt auch nur ein beschränktes Repertoir:
...

Bei der Behauptung bin ich über meine eigene Konfig mit 'MODULES=dep' in
/etc/initramfs-tools/conf.d/zz_MODULES gestolpert, ups
Natürlich ist bei einem gültigen Eintrag 'MODULES=most' die initrd prall gefüllt mit Controllertreibern usw.




---------------------

und man muss *jedesmal* neu booten

?

[cosmac]

Die Reihenfolge könnte dann auch noch wichtig sein,

Nein, in der initrd wird mit 'modprobe' gearbeitet, siehe
/init + /scripts/*

das ist ja grauenhaft, also ein klarer Fall von selbst schuld Aber mkinitramfs braucht doch die vollständige Liste, damit die module überhaupt in die initrd eingebaut werden.

MODULES=most bringt auch nur ein beschränktes Repertoir:
...

Bei der Behauptung bin ich über meine eigene Konfig mit 'MODULES=dep' in
/etc/initramfs-tools/conf.d/zz_MODULES gestolpert, ups
Natürlich ist bei einem gültigen Eintrag 'MODULES=most' die initrd prall gefüllt mit Controllertreibern usw.

... die ich zu 95% nicht gebraucht hätte. Gut, dass ich "MODULES=most" nicht gleich gefunden hab.

und man muss *jedesmal* neu booten

?

ja, *grml*. Muss man wohl, wenn man sowas wie initrd und rcS testen will.