Bug 254249 - RFE: Need to be able to specify order that modules are loaded
RFE: Need to be able to specify order that modules are loaded
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-08-24 19:01 EDT by Orion Poplawski
Modified: 2007-11-30 17:12 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-09-11 17:00:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Orion Poplawski 2007-08-24 19:01:02 EDT
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.
Comment 1 Jeremy Katz 2007-08-27 11:34:30 EDT
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? 
Comment 2 Orion Poplawski 2007-08-27 12:02:36 EDT
> 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.

Comment 3 Jeremy Katz 2007-08-27 13:20:29 EDT
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 :-/
Comment 4 Orion Poplawski 2007-09-05 13:47:08 EDT
(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?
Comment 5 David Cantrell 2007-09-05 13:55:33 EDT
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.
Comment 6 Jeremy Katz 2007-09-05 14:24:26 EDT
(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. 
Comment 7 Orion Poplawski 2007-09-13 11:56:05 EDT
(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.
Comment 8 Jeremy Katz 2007-09-13 13:17:23 EDT
(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.
Comment 9 Orion Poplawski 2007-09-13 13:52:30 EDT
(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).

Note You need to log in before you can comment on or make changes to this bug.