+++ This bug was initially created as a clone of Bug #316481 +++ Description of problem and the rationale. Anaconda needs to automatically (without passing command line options at boot) look for kernel modules and load them. The drivers will be packaged in the new redhat driver disk format. Dell suggests that this could be done in the loader, just after loading the driver disks in the usual method (linux dd). Code in RHEL 5.3 anaconda which searches for drivers on discovered media having a file system label OEMDRV needs to be forward-ported to Fedora rawhide.
The problem is that this ends up making it so that the user gets put into a situation where they're using unsupported (by the OS vendor) drivers when installing the OS. OS installation is tricky enough -- letting random vendors throw their own random bits and pieces to happen at various times just makes that worse, not better. Which is why it's far better that the user at least *opt into* it and know that they're going down the path as opposed to just having it happen behind their backs. I was against this initially and am still against it (and with more reasons the longer I think about it :-)
Mechanism vs policy my friend. I'm not opposed to policy being "only drivers produced and tagged by Red Hat will be supported by Red Hat". And I don't think having an anaconda / kernel command line option to enable the mechanism would be all that bad. (I prefer these things to "just work" without additional sysadmin knowledge of documented but never read options, but I can see the point of having such a command line option.) the fundamental problem I'm trying to solve is that customers, for better or worse, want to stick with an existing set of OS bits (e.g. their install image used on lots of machines, or a kickstart file which anaconda uses), while having sufficient device drivers for all hardware, both existing and future. Dell does a good job of getting drivers for new hardware into the upstream kernel as quickly as possible. But we can't always get such drivers into the kernel 6 months to 1 year ahead of time, which is the customer's deployment lifecycle for a given OS release. Hence there will always be a need for a "driver update process" (mechanism) of some sort, with policy for how/when it's used. Objections noted, the feature is now in RHEL 5.3. I expect it to still be there in RHEL 6. I believe this means it needs to be in F11 anaconda, where it can be exposed to a wide range of policy considerations, and appropriate mechanisms, if any, can be developed to implement the determined policies.
The patch is ready, it is just waiting for anaconda to stabilize due to our work on storage rewrite, which is changing the codebase a lot.
*** Bug 436951 has been marked as a duplicate of this bug. ***
Should be present in anaconda 11.5.0.37
Martin I checked at anaconda rawhide code (anaconda-11.5.0.57-1 I dont see any code related to auto pick up drivers from usb storage. Can you please point me to the code? Can you please let me know how to check if this feature is implemented. If this is not yet in tree, then please update the patches for auto pick up drivers from usb storage. Dell needs this feature to be there in Fedora-11 so that we can validate this before it is pushed to RHEL 6. Sandeep said it was designed to work with a boot option "ddlabel=<lable of partition containing drivers." I dont see this also being implemented.
Due to storage rewrite, this feature will be missing from F-11 and (re-)included into F-12. Sorry for the inconvenience.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This feature is now present in F13. Closing this bug as a part of my personal cleanup.