Preload modules before hardware detection? (wrong scsi order)
Hi, similar post was sent in July with title "Problem with the order of disks", where Michael Schulz had the same problem we have: SCSI controllers are detected in the wrong order, so that the disk that should be /dev/sda ends up as /dev/sde. This used to work with SuSE 9.0 where we loaded the module for the first controller with "insmod gdth" passed to linuxrc (we are using pxeboot). Now, with 10.1, the init process of YA starts a "Hardware detection" *before* loading the modules defined in the info file or passed to the command line. This makes the insmod option for linuxrc more or less superfluous and removes any control over the order in which modules are loaded during the AY boot. Here, it makes the fc modules load before the scsi modules, thus moving our scsi disk to /dev/sde. Is it possible to disable automatic hardware detection or load the modules before the hardware detection? Or could I try thinks like renaming the init binary in the initrd and install my own script there that's just modprobe gdth exec init.suse Of course, I would prefer a method without changing the initrd if possible... 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. *
On Friday 01 September 2006 14:38, Frank Steiner wrote:
Of course, I would prefer a method without changing the initrd if possible...
have you tried to use "/dev/disk/by-id/..." instead of "/dev/sdX"? The id should be always the same. That works since 10.1/SLES10 -- ciao, Uwe Gansert Uwe Gansert, Server Technologies Team SUSE LINUX Products GmbH, Maxfeldstrasse 5, D-90409 Nuernberg, Germany Business: http://www.suse.de/~ug now playing Agonoize - 999
Uwe Gansert wrote
On Friday 01 September 2006 14:38, Frank Steiner wrote:
Of course, I would prefer a method without changing the initrd if possible...
have you tried to use "/dev/disk/by-id/..." instead of "/dev/sdX"? The id should be always the same.
Not neccessarily, because the scsi disks are all hotswapable. So it can happen that we replace a disk due to to a failure (RAID1, so if one disk is exchanged, I'm not sure if the id changes?). Or in of the server we exchanged 147 by 300 GB between last autoyast install and now. Also, I don't know all the ids because the servers are still running kernel 2.6.8 where /dev/disk does not exist... I tried this: I moved init to init.suse and setup my own init script in the initrd, but it doesn't work yet. My init script looks like #!/bin/sh /sbin/modprobe gdth exec init.suse $@ Seems to work first, although after loading the module when calling init.suse I see: Moving into tmpfs... done Oops, pivot_root failed
SuSE Linux...
Then everything seems to work fine, but after "Loading the installation system" the installer comes up in textmode and does nothing automatically. Console 3 may give some hints, because there I see an error message: ... going for automatic install Loading image "/var/adm/mount/boot/i386/root"... error loading ramdisk ramdisk /dev/ram2 freed Usually some stuff is loaded here when autoyast runs fine. So I guess my "replace init"-approach is to simple. Is it possible to replace the SuSE init script in some way? 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. *
On Friday 01 September 2006 15:52, Frank Steiner wrote:
have you tried to use "/dev/disk/by-id/..." instead of "/dev/sdX"? The id should be always the same.
Not neccessarily, because the scsi disks are all hotswapable. So it can happen that we replace a disk due to to a failure (RAID1, so if one disk is exchanged, I'm not sure if the id changes?).
the id will change then. The "by-path" would stay the same but unfortunately, that's broken on 10.1/SLES10 (for SLES10 I have created a driverupdate to fix that and put that to http://www.suse.de/~ug).
and now. Also, I don't know all the ids because the servers are still running kernel 2.6.8 where /dev/disk does not exist...
I think the path is guessable.
I tried this: I moved init to init.suse and setup my own init script in the initrd, but it doesn't work yet. My init script looks like
#!/bin/sh /sbin/modprobe gdth exec init.suse $@
okay, I have never tried that and I can't say why that did not work or if it should.
Usually some stuff is loaded here when autoyast runs fine. So I guess my "replace init"-approach is to simple. Is it possible to replace the SuSE init script in some way?
hmm. I don't know. I would need to dig into that by myself. -- ciao, Uwe Gansert Uwe Gansert, Server Technologies Team SUSE LINUX Products GmbH, Maxfeldstrasse 5, D-90409 Nuernberg, Germany Business: http://www.suse.de/~ug now playing Agonoize - The holy Flame
On Fri, 1 Sep 2006, Frank Steiner wrote:
similar post was sent in July with title "Problem with the order of disks", where Michael Schulz had the same problem we have:
SCSI controllers are detected in the wrong order, so that the disk that should be /dev/sda ends up as /dev/sde.
This used to work with SuSE 9.0 where we loaded the module for the first controller with "insmod gdth" passed to linuxrc (we are using pxeboot). Now, with 10.1, the init process of YA starts a "Hardware detection" *before* loading the modules defined in the info file or passed to the command line.
That has been fixed in sles10 (bug #164213). If it's just about usb/firewire disks getting in the way, try booting with 'scsirename=1' (this used to be the default in <10.1 but has been turned off as a result of a bug report). Steffen
Steffen Winterfeldt wrote
This used to work with SuSE 9.0 where we loaded the module for the first controller with "insmod gdth" passed to linuxrc (we are using pxeboot). Now, with 10.1, the init process of YA starts a "Hardware detection" *before* loading the modules defined in the info file or passed to the command line.
That has been fixed in sles10 (bug #164213).
Is there a way to backport this bugfix into 10.1? Like patching yast modules via "driverupdate"? I don't know how, because "init" is a binary in the initrd used for AY and so I can't hack it... Is the source code of this init available somewhere? (shouldn't it due to GPL? Or is the init binary covered by some other kind of license?) If I could get into that init process, I could fix a lot myself :-) Or can I exchange the SL10.1 init (or whole root image) with the SLES10 one? So just using it for booting, but then pointing AY to the 10.1 repository for installation...? I don't mind pushing my own kernel into the install process, but I would feel better if I could fix that problem the right way :-) 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: -4054 * Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *
On Mon, 4 Sep 2006, Frank Steiner wrote:
Steffen Winterfeldt wrote
This used to work with SuSE 9.0 where we loaded the module for the first controller with "insmod gdth" passed to linuxrc (we are using pxeboot). Now, with 10.1, the init process of YA starts a "Hardware detection" *before* loading the modules defined in the info file or passed to the command line.
That has been fixed in sles10 (bug #164213).
Is there a way to backport this bugfix into 10.1? Like patching yast modules via "driverupdate"? I don't know how, because "init" is a binary in the initrd used for AY and so I can't hack it... Is the source code of this init available somewhere? (shouldn't it due to GPL? Or is the init binary covered by some other kind of license?) If I could get into that init process, I could fix a lot myself :-)
Just use the sles10 sources (linuxrc package), there's no separate 10.1 code branch. Or use the pre-10.2 code from opensuse.org (which is sles10 + even more bugfixes).
Or can I exchange the SL10.1 init (or whole root image) with the SLES10 one? So just using it for booting, but then pointing AY to the 10.1 repository for installation...? I don't mind pushing my own
Sure. As long as you don't mind the sles10-look. Steffen
Steffen Winterfeldt wrote
If I could get into that init process, I could fix a lot myself :-)
Just use the sles10 sources (linuxrc package), there's no separate 10.1 code branch. Or use the pre-10.2 code from opensuse.org (which is sles10 + even more bugfixes).
Thanks a lot! I wasn't aware of the linuxrc package.
Or can I exchange the SL10.1 init (or whole root image) with the SLES10 one? So just using it for booting, but then pointing AY to the 10.1 repository for installation...? I don't mind pushing my own
Sure. As long as you don't mind the sles10-look.
Cool. That's really a common code base :-) Thanks a lot for your help! 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 post that for people running into the same problem: Frank Steiner wrote:
SCSI controllers are detected in the wrong order, so that the disk that should be /dev/sda ends up as /dev/sde.
This used to work with SuSE 9.0 where we loaded the module for the first controller with "insmod gdth" passed to linuxrc (we are using pxeboot). Now, with 10.1, the init process of YA starts a "Hardware detection" *before* loading the modules defined in the info file or passed to the command line.
This makes the insmod option for linuxrc more or less superfluous and removes any control over the order in which modules are loaded during the AY boot. Here, it makes the fc modules load before the scsi modules, thus moving our scsi disk to /dev/sde.
I solved the problem by using our self-compiled kernel (in which we have only the module for the controller compiled in that should load as first controller, all others are modules) as installation kernel. This works well, but needs also some work on the initrd. We are booting the installation via PXE, so it's quite easy to pass our own kernel and our own initrd. What needs to be done: 1. compile your own kernel 2. use the vmlinuz file as kernel passed via PXE 3. replace all modules in the initrd passwd via PXE, and remove those that are now in the kernel, i.e. unpack the initrd and do sth. like cd unpacked_initrd/modules modulelist=`ls *.ko` # clean up, so that modules compiled into our kernel # aren't here anymore (with wrong, old format) rm -f *.ko for name in `echo $modulelist` do find /where_is_my_kernel/lib/modules -name $name -exec cp -a {} . \; || exit 1 done autoyast will beep whenever it tries to load a module that is compiled into the kernel, but everything works fine. It's not the best, but the only way I've found to make one driver load before the others (although replacing the init script should also work when I try a bit harder ;-)) 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. *
participants (3)
-
Frank Steiner -
Steffen Winterfeldt -
Uwe Gansert