[opensuse-autoinstall] insmod modules not considered?
Hi, we are passing some modules to the AY installer with insmod= via our pxelinux.cfg. But it seems that only some are loaded before the automatic hardware detection starts, and I don't understand which ones are and which ones are not. E.g. we have insmod=3w-9xxx insmod=scsi_mod insmod=dock insmod=libata insmod=ata_piix insmod=mptbase ... But only the 3ware controller is preloaded, the SATA not. On console 3 I see: ... insmod /modules/arc4.ko insmod /modules/3w-9xxx.ko insmod /modules/mptbase.ko ... Starting hardware detection... Thus, all the modules for the SATA controller are ignored. Same happens with "insmod=tg3 insmod=e1000" which loads the tg3 module, but not the e1000. What am I doing wrong here? cu, Frank -- Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/ Lehrstuhl f. Bioinformatik Mail: http://www.bio.ifi.lmu.de/~steiner/m/ LMU, Amalienstr. 17 Phone: +49 89 2180-4049 80333 Muenchen, Germany Fax: +49 89 2180-99-4049 * Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. * -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-autoinstall+help@opensuse.org
Hi, On Mon, 30 Mar 2009, Frank Steiner wrote:
we are passing some modules to the AY installer with insmod= via our pxelinux.cfg. But it seems that only some are loaded before the automatic hardware detection starts, and I don't understand which ones are and which ones are not.
E.g. we have
insmod=3w-9xxx insmod=scsi_mod insmod=dock insmod=libata insmod=ata_piix insmod=mptbase ...
But only the 3ware controller is preloaded, the SATA not. On console 3 I see:
which SUSE release are you using? Steffen -- Der frühe Wirt holt sich den Wurm. -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-autoinstall+help@opensuse.org
Steffen Winterfeldt wrote
E.g. we have
insmod=3w-9xxx insmod=scsi_mod insmod=dock insmod=libata insmod=ata_piix insmod=mptbase ...
But only the 3ware controller is preloaded, the SATA not. On console 3 I see:
which SUSE release are you using?
Sorry, I'm talking about SLED/SLES 11. -- Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/ Lehrstuhl f. Bioinformatik Mail: http://www.bio.ifi.lmu.de/~steiner/m/ LMU, Amalienstr. 17 Phone: +49 89 2180-4049 80333 Muenchen, Germany Fax: +49 89 2180-99-4049 * Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. * -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-autoinstall+help@opensuse.org
On Mon, 30 Mar 2009, Frank Steiner wrote:
Steffen Winterfeldt wrote
E.g. we have
insmod=3w-9xxx insmod=scsi_mod insmod=dock insmod=libata insmod=ata_piix insmod=mptbase ...
But only the 3ware controller is preloaded, the SATA not. On console 3 I see:
which SUSE release are you using?
Sorry, I'm talking about SLED/SLES 11.
Could it be the other modules have already been loaded (by udev at startup)? Steffen -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-autoinstall+help@opensuse.org
Steffen Winterfeldt wrote
Could it be the other modules have already been loaded (by udev at startup)?
Where could I see that? The output on console 3 starts with "remount of / ok", followed by a list of modules that I haven't specified (like lockd.ko, fan.kom nfs.ko etc.). Then follow some of my own modules, as described. I pressed Ctrl-S after I saw my modules started to load and then switched to console 9 and typed "lsmod". Indeed I see a lot of modules, like the e1000 or ata_piix in this list. Does it mean they were already loaded? If so, why did that happen? If all those modules are preloaded at some stage, then I could never ensure that a SCSI disks is detected before a SATA disk if ata_piix is always loaded before my own SCSI modules via insmod. I thought the insmod mechanism is meant to load modules before any other modules are loaded automatically, to override the order in which hardware is detected. My current problem is that the card reader devices fetch sda-sdd and the SATA disk is sde. I need the SATA disk to be sda and I can't start to work with by-id or by-path because we have too many different hosts systems (IDE+SCSI, Sata+SCSI, Sata+FC, IDE+Sata etc.). The only method we ever found to handle all of those was to ensure that the main disk is always detected as first disk by load-ordering the modules. So how can we ensure the sata disk is detected before the USB devices? cu, Frank -- Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/ Lehrstuhl f. Bioinformatik Mail: http://www.bio.ifi.lmu.de/~steiner/m/ LMU, Amalienstr. 17 Phone: +49 89 2180-4049 80333 Muenchen, Germany Fax: +49 89 2180-99-4049 * Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. * -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-autoinstall+help@opensuse.org
My current problem is that the card reader devices fetch sda-sdd and the SATA disk is sde. I need the SATA disk to be sda and I can't start to work with by-id or by-path because we have too many different hosts
Quick and untested solutions 1) remove any USB Storage support from the initrd and if required load it from the info file or later. ( My prefered solution ) or 2) use a pre-scripts to unload all storage devices and load them in the required order. or 3) disable USB* on the kernel command line like : kernel ... nousb ... *You might have to configure later the /etc/sysconfig/kernel (MODULES_LOADED_ON_BOOT) in case you would like to have USB support and loading the kernel devices in the right order after the installation and before the first reboot. hth Hajo -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-autoinstall+help@opensuse.org
Hans-Joachim Ehlers wrote
Quick and untested solutions
Thanks for caring! I guess I don't need them as long as I can disable udev as Stefan described. But I will test all of your proposed solutions just to see what possibilities I have to manipulate the boot process. Thanks! cu, Frank -- Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/ Lehrstuhl f. Bioinformatik Mail: http://www.bio.ifi.lmu.de/~steiner/m/ LMU, Amalienstr. 17 Phone: +49 89 2180-4049 80333 Muenchen, Germany Fax: +49 89 2180-99-4049 * Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. * -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-autoinstall+help@opensuse.org
On Mon, 30 Mar 2009, Frank Steiner wrote:
Steffen Winterfeldt wrote
Could it be the other modules have already been loaded (by udev at startup)?
Where could I see that? The output on console 3 starts with "remount of / ok", followed by a list of modules that I haven't specified (like lockd.ko, fan.kom nfs.ko etc.). Then follow some of my own modules, as described.
I pressed Ctrl-S after I saw my modules started to load and then switched to console 9 and typed "lsmod". Indeed I see a lot of modules, like the e1000 or ata_piix in this list.
Does it mean they were already loaded? If so, why did that happen?
udevd is responsible for module loading (as in the installed system).
If all those modules are preloaded at some stage, then I could never ensure that a SCSI disks is detected before a SATA disk if ata_piix is always loaded before my own SCSI modules via insmod. I thought the insmod mechanism is meant to load modules before any other modules are loaded automatically, to override the order in which hardware is detected.
'insmod' was there to load modules that were (for whatever reason) not loaded automatically.
My current problem is that the card reader devices fetch sda-sdd and the SATA disk is sde. I need the SATA disk to be sda and I can't start
You should really not rely on specific device names. The kernel does not guarantee a defined initialization order.
to work with by-id or by-path because we have too many different hosts systems (IDE+SCSI, Sata+SCSI, Sata+FC, IDE+Sata etc.). The only method we ever found to handle all of those was to ensure that the main disk is always detected as first disk by load-ordering the modules.
What is the 'main disk' for you? The one you will boot from? Then maybe /dev/disk/by-id/edd-int13_dev80 is a way.
So how can we ensure the sata disk is detected before the USB devices?
AFAIK, you can't (in a sensible way). If it's any help to you, you can get back the pre-SLES11/11.1 behavior with 'linuxrc.debug=-udev.mods' which will turn off module loading in udevd and linuxrc takes care again. Steffen -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-autoinstall+help@opensuse.org
Steffen Winterfeldt wrote
'insmod' was there to load modules that were (for whatever reason) not loaded automatically.
But that wasn't the intenton two years ago: -------- Original Message -------- Subject: Re: [opensuse-autoinstall] SuSE 10.1 autoyast and scsi device order Date: Tue, 22 May 2007 16:25:40 +0200 (CEST) From: Steffen Winterfeldt <snwint@suse.de> Steffen Winterfeldt wrote
starting with sles10, 'insmod=' options passed at the kernel command line are evaluated _before_ hardware detection.
So I guess it was intended exactly for what some of use used it: Force modules to be loaded before the system loads them automatically. I don't understand why udev must now run before?
My current problem is that the card reader devices fetch sda-sdd and the SATA disk is sde. I need the SATA disk to be sda and I can't start
You should really not rely on specific device names. The kernel does not guarantee a defined initialization order.
Not in theory, but in practice :-) I've heared this argument so many times over the last about 5 years, but when you ensure that the module of the hard disk you want to be the first one is loaded as first module, you will always get the disk with the first id of this controller as first hard disk. No controller is ever changing the order of its attached hard disks. We have IBM pSeries, Sun X2200 and X4100, IBM x335 and x345 and over 60 desktop clients from Tarox, HP, FSC, IBM and noname manufacturers. All of those are installed with the same autoyast profile, using "hda" or "sda" for partitioning. And with SLES10 we ensured that the right hard disk was always sda and hda with only three different pxelinux.cfg files. This just works great for us and our 150 hosts.
What is the 'main disk' for you? The one you will boot from? Then maybe /dev/disk/by-id/edd-int13_dev80 is a way.
We have enough PCs where this does not work, e.g. because the bios is too old or to restricted to list certain devices. And a bunch of problematic ASUS bioses which just have problem managing IDE and SCSI in parallel. Using the "load this module first, take sda/hda" always works.
So how can we ensure the sata disk is detected before the USB devices?
AFAIK, you can't (in a sensible way). If it's any help to you, you can get back the pre-SLES11/11.1 behavior with 'linuxrc.debug=-udev.mods' which will turn off module loading in udevd and linuxrc takes care again.
This definitely helps! Thanks! I know that you are all following the "clean" way that the kernel developers bring up, but the nice thing of Linux has always been that it was a Linux box and not an iPhone that I was managing, so I could always override the "good clean" way and hack all the dirty stuff, no matter how stupid it might look to others :-) Maybe you can return the now inofficial debug-feature into an official (so that we are sure it's kept) "let the user do whatever he wants" feature for SLES12. E.g. a linuxrc option "preins=e100" which loads the e100 module before *any* other module is loaded, so I can force linuxrc to use e100 instead of e1000. It wouldn't hurt to have an additional option, would it? But it would help those of us hackers who are just happy with the good old way. I don't know how to translate this, but when my kids play they often say "Ich bin jetzt mal der Bestimmer!" And that's what I want to be when I install Linux. I don't want to let udev take decisions for me that I can't override... Thanks for the debug option! And please think about a "preins" or sth :-) cu, Frank -- Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/ Lehrstuhl f. Bioinformatik Mail: http://www.bio.ifi.lmu.de/~steiner/m/ LMU, Amalienstr. 17 Phone: +49 89 2180-4049 80333 Muenchen, Germany Fax: +49 89 2180-99-4049 * Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. * -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-autoinstall+help@opensuse.org
On Mon, 30 Mar 2009, Frank Steiner wrote:
Steffen Winterfeldt wrote
starting with sles10, 'insmod=' options passed at the kernel command line are evaluated _before_ hardware detection.
So I guess it was intended exactly for what some of use used it: Force modules to be loaded before the system loads them automatically. I don't
Nyes. The point is 'before hardware detection' (== linuxrc's hardware detection). And that is still true. The 'insmod' option is there to load modules that otherwise wouldn't and to be of any use this should be done before linuxrc checks the hardware.
understand why udev must now run before?
udev is the canonical way to load modules at startup. While this may still cause problems, this also means that bugs in this area are going to be addressed by the udev upstream maintainers. But...
You should really not rely on specific device names. The kernel does not guarantee a defined initialization order.
Not in theory, but in practice :-) I've heared this argument so many times over the last about 5 years, but when you ensure that the module of the hard
... unfortunately, module loading order does not qualify. :-)
Maybe you can return the now inofficial debug-feature into an official
Oh, it's officially documented at http://en.opensuse.org/Linuxrc. :-)
(so that we are sure it's kept) "let the user do whatever he wants" feature for SLES12. E.g. a linuxrc option "preins=e100" which loads the e100 module
Something like that. Maybe 'insmod' just needs to be evaluated earlier. I'll keep it in mind. Steffen -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-autoinstall+help@opensuse.org
Steffen Winterfeldt wrote
Nyes. The point is 'before hardware detection' (== linuxrc's hardware detection). And that is still true. The 'insmod' option is there to load modules that otherwise wouldn't and to be of any use this should be done before linuxrc checks the hardware.
Ok, that was just a bit confusing because of the two different hardware detections, udev and linuxrc :-)
Maybe you can return the now inofficial debug-feature into an official
Oh, it's officially documented at http://en.opensuse.org/Linuxrc. :-)
I missed that docu, sorry :-) I just meant that an option like "linuxrc.debug" sounds like it could vanish without notice from one release to the other, because it's not a real feature but just debugging stuff... You get what I mean :-)
(so that we are sure it's kept) "let the user do whatever he wants" feature for SLES12. E.g. a linuxrc option "preins=e100" which loads the e100 module
Something like that. Maybe 'insmod' just needs to be evaluated earlier. I'll keep it in mind.
Thanks for caring! Btw, with the debug option everything now works fine again for our servers! cu, Frank -- Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/ Lehrstuhl f. Bioinformatik Mail: http://www.bio.ifi.lmu.de/~steiner/m/ LMU, Amalienstr. 17 Phone: +49 89 2180-4049 80333 Muenchen, Germany Fax: +49 89 2180-99-4049 * Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. * -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-autoinstall+help@opensuse.org
participants (3)
-
Frank Steiner -
Hans-Joachim Ehlers -
Steffen Winterfeldt