Description of problem: The random nature of driver load order pretty much makes it impossible to script installs of machines with multiple disk controllers. We need at least a way to specify a module to get loaded first which will hold the boot disks. It would also be nice if it could automatically load the driver for the bios boot disk first.
Really, though, if you're depending on module load order, you've already lost. Because even if we changed and added that, it still wouldn't guarantee anything about detection order due to the increasingly asynchronous nature of device detection within the kernel. What are you trying to do that's depending on the device name?
> What are you trying to do that's depending on the device name? clearpart --all --drives=sda,sdb --initlabel For example, the system in question (though there are several issues like this) has two scsi boot drives that hold the os in a raid1 setup. This uses the aic7xxxx driver. It also has a Promise SATA controller. When I go to install sata_promise is loaded before aic7xxxx and the above drive naming is not correct. If there is a better way to do this, I'm all ears.
Right now, your best approach is to use %pre to generate the partitioning info. Really, we need to come up with better ways to "name" disk devices that aren't dependent on ordering. But that ends up being incredibly painful :-/
(In reply to comment #3) > Right now, your best approach is to use %pre to generate the partitioning info. This seems like a lot of work. I've got to work out some way to iterate over the various disks, determine which one will be the boot disk. It seems a lot easier to be able to specify which module to load first so the the boot disk is always sda. Is this a hard request to satisfy?
It depends on how you look at the problem. For the average user, this is something that's very doable if they are handed a shell and told to run modprobe to set up their devices. However, we are anaconda and anaconda doesn't necessarily know what's in your system. This problem sits on the fine line between what should anaconda be doing to set up devices and what should the kernel do for us? It's the kind of problem we'd like to solve once and not add hacks for on an ongoing basis.
(In reply to comment #4) > (In reply to comment #3) > > Right now, your best approach is to use %pre to generate the partitioning info. > > This seems like a lot of work. I've got to work out some way to iterate over > the various disks, determine which one will be the boot disk. It seems a lot > easier to be able to specify which module to load first so the the boot disk is > always sda. Is this a hard request to satisfy? Read my original response. Module load order guarantees nothing about drive discovery order and thus drive naming still isn't guaranteed like you want.
(In reply to comment #6) > Read my original response. Module load order guarantees nothing about drive > discovery order and thus drive naming still isn't guaranteed like you want. Really? Then what was the point of the "scsi-hostadapter" lines in /etc/modprobe.conf if not to control ordering? I've been using that for years for that very purpose on one of our disk servers.
(In reply to comment #7) > (In reply to comment #6) > > Read my original response. Module load order guarantees nothing about drive > > discovery order and thus drive naming still isn't guaranteed like you want. > > Really? Then what was the point of the "scsi-hostadapter" lines in > /etc/modprobe.conf if not to control ordering? I've been using that for years > for that very purpose on one of our disk servers. And for years it worked. But the kernel has been moving in the direction of having disk scanning be asynchronous from module load for the past 12-18 months. Currently, it's only the case with _some_ devices, but within the next 6 months, it's going to end up being all.
(In reply to comment #8) > And for years it worked. But the kernel has been moving in the direction of > having disk scanning be asynchronous from module load for the past 12-18 months. > Currently, it's only the case with _some_ devices, but within the next 6 > months, it's going to end up being all. Crap. This is going to play havoc with tar --listed-incremetal backups (e.g. with amanda).