monster initrd

[hampi]

Servus zusammen,

das mkinitrd-Script von OpenSUSE 11 hat einen Schalter

-A     Create a so called "monster initrd" which includes all  features and modules possible.

Fällt jemandem eine Möglichkeit ein, das unter Fedora/RedHat/CentOS nachzuahmen? Alle SCSI/ATA-Module per

mkinitrd --with=modulname1 --with=modulname2 ... --with=modulenameN

in die initrd einzubinden funktioniert zwar, nach dem booten sind aber 99% der geladenen Mass-Storage-Module unnötigerweise immer noch geladen, weil das init-Script der ramdisk einfach alle Module per insmod lädt, egal ob die entspr. Hardware im Rechner vorhanden ist oder nicht.

 

[Gast1]

Deine Idee ist in sich widersprüchlich.

Zuerst willst Du alle Module einbinden (warum auch immer) und dann wunderst Du Dich, daß sie auch alle geladen werden.

Das ist aber genau eine der Aufgaben der initrd, Module bereitzustellen, bevor die HW-Erkennung (udev & co.) es machen _können_.

Das kann nur dann selektiv sein, wenn man nur die Module einbindet, die man auch braucht.

 

[hampi]

Deine Idee ist in sich widersprüchlich.
Zuerst willst Du alle Module einbinden (warum auch immer) und dann wunderst Du Dich, daß sie auch alle geladen werden.

Ich wundere mich nicht, ich stelle fest. Dass alle Module, die ich mit --with einbinde auch geladen werden, ist schließlich Sinn der Sache.

Suse hat mit dem Schalter -A mkinitrd so erweitert, dass alle vorhandenen Module in die initrd kopiert, aber nur die benötigten beim Systemstart geladen werden.

Meine Frage ist: gibt's das auch unter CentOS/Fedora/Redhat? Bevor ich mich daran mache, die Skripten von Suse so anzupassen, dass die auch unter den Redhat-Derivaten laufen, frage ich lieber nach.

 

[Gast1]

Dann verstehe ich den Satz hier nicht, wenn Dir der Sinn der Sache klar ist.

in die initrd einzubinden funktioniert zwar, nach dem booten sind aber 99% der geladenen Mass-Storage-Module unnötigerweise immer noch geladen, weil das init-Script der ramdisk einfach alle Module per insmod lädt, egal ob die entspr. Hardware im Rechner vorhanden ist oder nicht.

Aber egal.

Ich hab zwar kein Fedora/RH aber prinzipiell muss das möglich sein, das Ganze auf eine andere Distribution anzupassen (mit exakt dem selben Ergebnis).

Vielleicht geht das aber auch einfacher:

Fedora/RH bieten doch auch LSB-konforme Config in /etc/sysconfig an?

Bei openSUSE gibt es die Option "INITRD_MODULES" in /etc/sysconfig/kernel mit welcher man angeben kann, welche Module in die initrd kommen sollten.

Vielleicht hat RH/Fedora ja etwas Vergleichbares (bin mir da eigentlich ziemlich sicher) und man kann sich das Gefummel am mkinitrd-Script sparen.

Greetz,

RM

 

[hampi]

Fedora/RH bieten doch auch LSB-konforme Config in /etc/sysconfig an?

Bei openSUSE gibt es die Option "INITRD_MODULES" in /etc/sysconfig/kernel mit welcher man angeben kann, welche Module in die initrd kommen sollten.

Vielleicht hat RH/Fedora ja etwas Vergleichbares (bin mir da eigentlich ziemlich sicher) und man kann sich das Gefummel am mkinitrd-Script sparen.
RM

Module in "INITRD_MODULES" werden auf jeden Fall geladen. Das möchte ich aber nicht.

Beispiel: Rechner A hat IDE-Controller X, Rechner B SCSI-Controller Y. Ein einfacher Umzug von A nach B ohne ändern der initrd ist hier nicht möglich. Das möchte ich aber (für ein Image/Restore-Szenario).

Die monster-initrd von Suse >= 11.0 bietet genau dieses Feature. Es werden alle möglichen Module in die initrd kopiert (also auch die für Hardware, die im aktuellen Rechner nicht verbaut ist). Ändert sich die HW-Konfiguration wird automatisch das entspr. Modul nachgeladen, ohne dass ich irgendwas an irgendeiner Konfig-Datei ändern muss. Ich kann also ganz komfortabel einen Server, der eine Monster-RD besitzt bei Hardware-Fehler z.B. in einem Vmware umziehen, ohne was an der initrd ändern zu müssen.

Das würde ich mit Redhat und seinen Clones gern auch machen. Mit mkinitrd --with klappt's aber nicht...

Idee?

 

[Gast1]

Das Problem ist aber, was machst Du bei einem Kernelupdate?

Da müsstest Du dann ohne Eintrag in die entsprechende Config-Datei (bei SUSE eben INITRD_MODULES) auch die "Monster"-Initrd von Hand erzeugen lassen, damit die Kiste auch mit dem neuen Kernel sicher startet und auch um sie für den nächsten "Umzug" in Hinterhand zu haben.

Beim "Serverumzug" wird ja auch die entsprechende Config-Datei (welche die Aufzählung Module enthält) mit umgezogen.

Stehen die benötigten Module in der entsprechenden Config-Datei drin, dann wird das bei jedem Kernelupdate automatisch gemacht.

Was ist also einfacher?

Einmal eine "Monster-Config" erstellen und diese mit "umziehen" oder ständig bei jedem Kernelupdate und vor dem Neustart einmal "mkinitrd -A" oder etwas für Fedora/RH Vergleichbares (möglicherweise Marke Eigenbau) ausführen zu müssen, weil sonst die Kiste nicht mehr startet?


//Nachtrag:

Ich habe mal aus Spaß eine "Monster-Initrd" angelegt.

Dir geht es doch nur um bestimmte Module, insbesondere Treiber für SATA-Controller, richtig?

Da wird aber noch etwas mehr eingebaut, was mit Sicherheit mehr Platz wegnimmt als eine Hand voll "unnötig" geladener Kernelmodule.

mkinitrd -A

Kernel image:   /boot/vmlinuz-2.6.25.16-0.1-default
Initrd image:   /boot/initrd-2.6.25.16-0.1-default
Root device:    /dev/disk/by-id/ata-ST9100823A_3LG00M1F-part5 (/dev/sda5) (mounted on / as ext3)
Resume device:  /dev/disk/by-uuid/4a0a573f-ae24-43a8-aab4-4746094945a1 (/dev/sda8)
Kernel Modules: dock scsi_mod libata ata_piix processor thermal fan jbd mbcache ext3 edd dm-mod dm-snapshot ahci pata_amd pata_oldpiix pata_hpt37x pcmcia_core firmware_class pcmcia pata_pcmcia pata_sis sata_sis pata_cmd64x pata_marvell pata_ns87415 pata_radisys pata_pdc2027x pata_pdc202xx_old pata_jmicron pata_qdi pata_via pata_mpiix pata_triflex pata_acpi sata_uli pata_netcell sata_mv pata_cmd640 pata_winbond pata_atiixp pata_sc1200 pata_artop pata_cs5520 pata_serverworks pata_sil680 sata_promise ata_generic pata_it8213 sata_inic162x sata_sx4 pata_hpt3x3 pata_hpt3x2n pata_cypress sata_sil pata_hpt366 sata_nv pata_cs5530 pata_ninja32 sata_sil24 pata_ali pdc_adma pata_opti sata_via pata_it821x pata_legacy pata_cs5535 sata_vsc pata_isapnp pata_ns87410 pata_optidma pata_cs5536 sata_svw pata_rz1000 pata_efar sata_qstor pata_sl82c105 ide-core piix triflex pdc202xx_old cmd64x delkin_cb atiixp alim15x3 cs5520 slc90e66 sis5513 serverworks opti621 ns87415 amd74xx via82cxxx cs5535 trm290 sc1200 cy82c693 hpt366 hpt34x aec62xx jmicron cmd640 siimage it821x it8213 cs5530 pdc202xx_new rz1000 ide-pci-generic ide-tape ide-pnp qd65xx ali14xx ide_platform umc8672 ht6560b ide-cs dtc2278 ide-floppy cdrom ide-cd_mod ide-generic ide-disk scsi_transport_spi t128 aha1542 initio gdth in2000 dpt_i2o aacraid dc395x dtc scsi_debug hptiop u14-34f aic7xxx_old advansys parport ppa ipr scsi_transport_sas libsas imm sd_mod scsi_tgt libsrp pas16 megaraid_sas megaraid_mm megaraid_mbox wd7000 g_NCR5380 3w-9xxx qlogicfas408 qlogicfas sr_mod qla1280 scsi_transport_iscsi libiscsi stex st arcmsr 3w-xxxx sym53c416 tmscsim NCR53c406a fdomain g_NCR5380_mmio ultrastor eata ch sg scsi_transport_fc dmx3191d nsp_cs qlogic_cs fdomain_cs aha152x_cs sym53c500_cs aha152x BusLogic enclosure ses ips a100u2w qla4xxx atp870u aic79xx aic7xxx sym53c8xx osst lpfc ide-scsi aic94xx nsp32 mvsas qla2xxx iscsi_tcp megaraid raid_class scsi_transport_srp scsi_wait_scan ieee1394 ohci1394 af_packet cxgb3 appletalk ltpc ipddp cops skge eexpress slhc ppp_generic pppox pppoe natsemi myri10ge 8390 3c503 lp486e de600 e2100 cxgb ac3200 hp sb1000 ixgb mii 8139cp ppp_synctty niu eth16i eql typhoon macvlan cassini dl2k lanstreamer tms380tr skisa proteon smctr olympic tmspci 3c359 ibmtr abyss 82596 libphy vitesse lxt icplus realtek qsemi mdio-bitbang marvell cicada davicom broadcom smsc hdlc lapb hdlc_x25 n2 pc300too dlci sdla wanxl hdlc_raw_eth farsync syncppp z85230 x25_asy hostess_sv11 lmc lapbether c101 hdlc_raw sealevel hdlc_cisco pci200syn hdlc_fr cs89x0 zlib_deflate ppp_deflate sungem_phy sungem sky2 ifb mlx4_core ni52 forcedeth depca veth usbcore kaweth usbnet cdc_ether zaurus cdc_subset mcs7830 dm9601 rfkill hso asix net1080 rndis_host plusb gl620a pegasus rtl8150 catc ssb b44 tehuti virtio_net arcnet rfc1051 com90xx arc-rawmode arc-rimi rfc1201 capmode com90io 3c501 enc28j60 bnx2 acenic sis900 sunhme smc9194 vcan tun netxen_nic e1000 ns83820 sk98lin slip e100 ne crc-ccitt irda ksdazzle-sir sir-dev mcp2120-sir toim3232-sir girbil-sir esi-sir ma600-sir smsc-ircc2 ks959-sir tekram-sir mcs7780 litelink-sir vlsi_ir nsc-ircc ali-ircc w83977af_ir irtty-sir irda-usb via-ircc actisys-sir stir4200 old_belkin-sir donauboe kingsun-sir act200l-sir hp-plus skfp sis190 3c509 ppp_mppe r8169 lance bonding rndis_wlan prism54 ieee80211_crypt ieee80211 libertas libertas_cs usb8xxx mmc_core libertas_sdio wavelan hermes orinoco ipw2100 spectrum_cs atmel atmel_cs eeprom_93cx6 cfg80211 mac80211 rt2x00lib rt2x00pci rt2400pci rt2x00usb rt2500usb crc-itu-t rt61pci rt2500pci rt73usb rtl8180 led-class input-polldev b43 atmel_pci p54common wl3501_cs b43legacy rtl8187 orinoco_pci zd1211rw orinoco_plx ipw2200 p54pci hostap hostap_cs hostap_plx hostap_pci iwl3945 iwlcore iwl4965 ray_cs orinoco_cs wavelan_cs strip zd1201 orinoco_nortel orinoco_tmd p54usb airo airo_cs netwave_cs adm8211 atl1 znet pcnet_cs nmclan_cs smc91c92_cs xirc2ps_cs axnet_cs 3c589_cs 3c574_cs ibmtr_cs fmvj18x_cs crc16 ax25 mkiss scc yam hdlcdrv baycom_ser_hdx baycom_par 6pack baycom_ser_fdx baycom_epp bpqether starfire ipg 3c515 wd de620 sundance tlan ewrk3 hamachi 3c507 epic100 3c505 fealnx 3c59x hp100 r6040 ne2k-pci e1000e de4x5 uli526x xircom_cb winbond-840 tulip de2104x dmfe igb smc-ultra bnx2x seeq8005 rrunner atp eepro via-rhine pppol2tp yellowfin pcnet32 plip sc92031 tg3 via-velocity 8139too amd8111e qla3xxx s2io ppp_async ixgbe ni65 bsd_comp at1700 dummy configfs netconsole eepro100 ohci-hcd uhci-hcd ehci-hcd ff-memless hid usbhid libcrc32c crc32c cifs dm-multipath dm-round-robin dm-emc dm-hp-sw dm-rdac sunrpc nfs_acl lockd nfs raid0 raid1 xor async_tx async_memcpy async_xor raid456 linear crypto_blkcipher dm-crypt
cp: Aufruf von stat für „/sbin/dasdview“ nicht möglich: Datei oder Verzeichnis nicht gefunden
cp: Aufruf von stat für „/sbin/dasdinfo“ nicht möglich: Datei oder Verzeichnis nicht gefunden
cp: Aufruf von stat für „/sbin/dasd_configure“ nicht möglich: Datei oder Verzeichnis nicht gefunden
cp: Aufruf von stat für „/sbin/iscsid“ nicht möglich: Datei oder Verzeichnis nicht gefunden
cp: Aufruf von stat für „/sbin/iscsiadm“ nicht möglich: Datei oder Verzeichnis nicht gefunden
cp: Aufruf von stat für „/sbin/fwparam_ibft“ nicht möglich: Datei oder Verzeichnis nicht gefunden
cp: Aufruf von stat für „/sbin/multipath“ nicht möglich: Datei oder Verzeichnis nicht gefunden
cp: Aufruf von stat für „/lib/multipath/*“ nicht möglich: Datei oder Verzeichnis nicht gefunden
cp: Aufruf von stat für „/sbin/evms_activate“ nicht möglich: Datei oder Verzeichnis nicht gefunden
cp: Aufruf von stat für „/sbin/evms“ nicht möglich: Datei oder Verzeichnis nicht gefunden
which: no busybox in (/sbin:/usr/sbin:/usr/sbin:/sbin:/opt/kde3/bin:/home/axel/bin:/usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/usr/games:/opt/gnome/bin:/usr/lib/jvm/jre/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin:/usr/lib/qt3/bin)
cp: Aufruf von stat für „“ nicht möglich: Datei oder Verzeichnis nicht gefunden
Features:       vendor dm block dasd firewire network usb zfcp iscsi netconsole cifs dmraid multipath nfs kpartx md evms lvm2 luks resume.userspace resume.kernel busybox
Bootsplash:     PLASMA-WIND (1024x768)
[BUSYBOX] No Busybox executable was found
ldd: /sbin/dasdview: Datei oder Verzeichnis nicht gefunden
ldd: /sbin/dasdinfo: Datei oder Verzeichnis nicht gefunden
ldd: /sbin/dasd_configure: Datei oder Verzeichnis nicht gefunden
ldd: /sbin/iscsid: Datei oder Verzeichnis nicht gefunden
ldd: /sbin/iscsiadm: Datei oder Verzeichnis nicht gefunden
ldd: /sbin/fwparam_ibft: Datei oder Verzeichnis nicht gefunden
ldd: /sbin/multipath: Datei oder Verzeichnis nicht gefunden
ldd: /lib/multipath/*: Datei oder Verzeichnis nicht gefunden
ldd: /sbin/evms_activate: Datei oder Verzeichnis nicht gefunden
ldd: /sbin/evms: Datei oder Verzeichnis nicht gefunden
ldd: ./: Keine reguläre Datei
64072 blocks

Und selbst das liesse sich entsprechend konfigurieren und in eine Config eintragen.

Was da alles drin steht, ist jedenfalls alles sicher deutlich mehr Ballast als eine Handvoll unnötig geladener SATA-Treiber.

Greetz,

RM

 

[hampi]

An ein Kernelupdate hatte ich noch gar nicht gedacht. Danke für den Hinweis.

Wenn ich alle möglichen Module in "INITRD_MODULES" (ich nehme an, das meinst Du mit "Monster-Config"?) hineinschreibe, werdengrub alle geladen, auch die nicht benötigten. Wie schmeisse ich die nicht benötigten wieder raus?

 

[hampi]

Dir geht es doch nur um bestimmte Module, insbesondere Treiber für SATA-Controller, richtig?

Nein, mir geht's darum, ein Image eines Systems ohne weiter was dran machen zu müssen auf einem anderen System restoren zu können. Und das geht mit der Monster-initrd von Suse hervorragend.
Auf welchen Ballast beziehst Du Dich? Hast Du die monster-disk mal gebootet?

 

[Gast1]

Nein, mir geht's darum, ein Image eines Systems ohne weiter was dran machen zu müssen auf einem anderen System restoren zu können. Und das geht mit der Monster-initrd von Suse hervorragend.

Das ist mir schon klar, daß da noch etwas mehr gemacht wird als "nur" alle Module in die initrd zu klatschen, sieht man ja anhand der eingebundenen Module/Services.

Auf welchen Ballast beziehst Du Dich?

Hast Du doch selbst geschrieben, die unnötigen extra-Module, die geladen werden.

Wenn die Monster-Initrd das erst gar nicht macht oder (was auch möglich wäre) einen Mechanismus hat, der nachträglich die "unnötigen" Module entlädt, dann wird man herausfinden müssen, wie das implementiert wird.

Eine Idee wäre, daß versucht wird, sämtliche Module zu entladen bevor udev "loslegt".

Jene, die "in use" sind, können nicht entladen werden, den Rest erledigt dann udev.

Wie das genau gemacht wird, weiß ich nicht.

Greetz,

RM

 

[hampi]

Wenn die Monster-Initrd das erst gar nicht macht oder (was auch möglich wäre) einen Mechanismus hat, der nachträglich die "unnötigen" Module entlädt, dann wird man herausfinden müssen, wie das implementiert wird.

Im Endeffekt war genau das der Grund meines Postings :-). Ich werd mich mal näher mit SUSEs mkinitrd-Skripten beschäftigen.

Danke für Deine Anmerkungen

 

[Gast1]

Zumindest findet sich in /lib/mkinitrd/scripts ne ganze Menge, z.B. auch ein "setup-udev.sh".

Scheinbar kann man da auch udev in die initrd packen und das würde erklären, wie die Monster-initrd "weiß" welche Module sie laden muss und welche nicht.

Greetz,

RM

 

[hampi]

Scheinbar kann man da auch udev in die initrd packen und das würde erklären, wie die Monster-initrd "weiß" welche Module sie laden muss und welche nicht.

Wobei udev auch in der normalen SUSE-ramdisk enthalten ist und auch geladen wird. CentOS z.B. macht das nicht. Ich komm um eine nähere Analyse der SUSE-Scripts leider nicht rum.

Ich freu mich schon auf den Tag, an dem die ramdisk-Geschichte bei allen Distris wenn nicht gleich, so zumindest ähnlich ist.