Bug 489314

Summary:	Need anaconda to pick up drivers from usb storage without any command line options
Product:	[Fedora] Fedora	Reporter:	Matt Domsch <matt_domsch>
Component:	anaconda	Assignee:	Martin Sivák <msivak>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	medium
Version:	11	CC:	anaconda-maint-list, andriusb, atodorov, bzeranski, charles_rose, cward, jcm, jfeeney, jlaska, matt_domsch, msivak, paniraja_km, pjones, rmaximo, sandeep_k_shandilya, syeghiay, vanmeeuwen+fedora, wwlinuxengineering
Target Milestone:	---	Keywords:	Reopened
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:	316481	Environment:
Last Closed:	2010-04-06 08:34:48 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	316481
Bug Blocks:

Description Matt Domsch 2009-03-09 13:13:02 UTC

+++ 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.

Comment 1 Jeremy Katz 2009-03-09 19:03:22 UTC

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 :-)

Comment 2 Matt Domsch 2009-03-09 19:48:53 UTC

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.

Comment 3 Martin Sivák 2009-03-11 09:22:09 UTC

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.

Comment 4 Martin Sivák 2009-03-11 09:49:49 UTC

*** Bug 436951 has been marked as a duplicate of this bug. ***

Comment 5 Martin Sivák 2009-03-24 13:34:44 UTC

Should be present in anaconda 11.5.0.37

Comment 6 Paniraj 2009-06-01 11:26:47 UTC

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.

Comment 7 Martin Sivák 2009-06-01 11:57:33 UTC

Due to storage rewrite, this feature will be missing from F-11 and (re-)included into F-12. Sorry for the inconvenience.

Comment 8 Bug Zapper 2009-06-09 12:02:30 UTC

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

Comment 9 Martin Sivák 2010-04-06 08:34:48 UTC

This feature is now present in F13. Closing this bug as a part of my personal cleanup.