-----Original Message----- From: Frank Steiner [mailto:fsteiner-mail1@bio.ifi.lmu.de] Sent: Friday, September 01, 2006 8:39 AM To: suse-autoinstall@suse.com Subject: [suse-autoinstall] 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
I spent a bunch of time going around and around with this basic problem -- a machine with two SATA controllers, and the wrong one was being detected first. (System array is on a Silicon Image controller, Storage array is on a 3ware card -- and detection happens in alphabetical order).
In the end, I found it easier to make a chroot-script that basically just does this: `sed -i "s/3w_9xxx sata_sil/sata_sil 3w_9xxx/g" /etc/sysconfig/kernel` `mkinitrd`
(replace the module names, of course, with the ones relevant to your environment.)
This just takes advantage of the fact that, by the time chroot scripts run, the sysconfig/kernel file is already populated (having just been used to build the "broken" initrd).
The trick, here, is that you're installing to /dev/sde, but it's going to be /dev/sda when the system boots. The bootloader section, at least, needs to be adjusted to handle that case.
I'm a little fortunate in that the sed regex is always the same in my environment. A more generalized version, though, could be done with something like `sed -i "s/3w_9xxx(.*)sata_sil/sata_sil\13w_9xxx/g" /etc/sysconfig/kernel`
Anyway...your mileage with my hacks may vary, but hope this helps a little...
- Ian
Marlier, Ian wrote
The trick, here, is that you're installing to /dev/sde, but it's going to be /dev/sda when the system boots. The bootloader section, at least, needs to be adjusted to handle that case.
That doesn't help, because then I must rely on my boot disk being always /dev/sde, because I must specify it in the profile. But in this case, /dev/sda - /dev/sdd are external disk on a fibre channel bus. I cannot rely on all of them always being online. So, sometimes my internal scsi disk could be /dev/sde, sometimes /dev/sdc or sth.
To circumvent this, our solution has been to always load the module for the internal scsi disk as first module. So we can be sure we will be working on /dev/sda, because the internal disks are the only ones that will never vanish :-)
On Friday 01 September 2006 09:19, Marlier, Ian wrote:
-----Original Message----- From: Frank Steiner [mailto:fsteiner-mail1@bio.ifi.lmu.de] Sent: Friday, September 01, 2006 8:39 AM To: suse-autoinstall@suse.com Subject: [suse-autoinstall] 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
I spent a bunch of time going around and around with this basic problem -- a machine with two SATA controllers, and the wrong one was being detected first. (System array is on a Silicon Image controller, Storage array is on a 3ware card -- and detection happens in alphabetical order).
In the end, I found it easier to make a chroot-script that basically just does this: `sed -i "s/3w_9xxx sata_sil/sata_sil 3w_9xxx/g" /etc/sysconfig/kernel` `mkinitrd`
(replace the module names, of course, with the ones relevant to your environment.)
This is silly. Why don't you just use the initrd_modules clause like the following?
<initrd_modules config:type="list"> <initrd_module> <module>mptsas</module> </initrd_module> <initrd_module> <module>scsi_mod</module> </initrd_module> <initrd_module> <module>sd_mod</module> </initrd_module> <initrd_module> <module>aic7xxx</module> </initrd_module> .... (and so on)
It seemed to work for us if we have disks on different types of controllers. But there is still one remaining problem. If we have multiple disks on the same controller the order seems to be different in the installation system compared to the installed system. For instance, on a SunFire X4100 we have 4 SAS drives, two of them are combined to a RAID 1 via the controller. During installation this seems to become /dev/sda but after the first reboot it becomes /dev/sdc. We haven't found a good solution to that one yet (except creating two RAID 1 arrays but this is just a crude workaround). We haven't tried the /dev/disk-byid/... stuff yet.
This just takes advantage of the fact that, by the time chroot scripts run, the sysconfig/kernel file is already populated (having just been used to build the "broken" initrd).
The trick, here, is that you're installing to /dev/sde, but it's going to be /dev/sda when the system boots. The bootloader section, at least, needs to be adjusted to handle that case.
I'm a little fortunate in that the sed regex is always the same in my environment. A more generalized version, though, could be done with something like `sed -i "s/3w_9xxx(.*)sata_sil/sata_sil\13w_9xxx/g" /etc/sysconfig/kernel`
Anyway...your mileage with my hacks may vary, but hope this helps a little...
- Ian
Karsten.
autoinstall@lists.opensuse.org
-
Frank Steiner -
Karsten Künne -
Marlier, Ian