[Feature Request] Add support for Dell Driver Injection Disk

Bug #341526 reported by Mario Limonciello
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Fedora
Fix Released
High
Suse
Unknown
Unknown
hw-detect (Ubuntu)
Fix Released
Wishlist
Colin Watson
Hardy
Won't Fix
Wishlist
Unassigned
Karmic
Fix Released
Wishlist
Colin Watson
mountmedia (Ubuntu)
Fix Released
Wishlist
Colin Watson
Hardy
Won't Fix
Wishlist
Unassigned
Karmic
Fix Released
Wishlist
Colin Watson

Bug Description

Upcoming Dell servers will be supporting a new technology called "Driver Injection Disks". These are essentially read only flash drives that are connected internally on the USB bus containing drivers preloaded from the factory.

They are intended to be used during OS installation for an OS release that doesn't yet include support for the drivers in a server natively. RHEL and SLES have both adopted it already into their installers.

Here are the key points about it:
1) It will show up as a VFAT disk with the label OEMDRV
2) Drivers from many OSes may be contained on the VFAT disk at any given time. This means that if a server is certified against Ubuntu 8.04, RHEL 5.3, Windows Server 2008, and Ubuntu 10.04, that drivers will be on for each of these OSes. Because of this, it's important to account for possible collisions. For Ubuntu releases, this is solved by shipping Ubuntu drivers in:
$mnt/ubuntu/$(lsb_release -r -s). Drivers for Ubuntu 8.04 will not be offered with Ubuntu 10.04 installs then.
3) This VFAT disk will always be exposed as read only to the user during installation. Using Dell supported tools however, it can be injected with updated drivers if the customer would like.
4) This option should be preseedable, so in the event that Dell was to ship an Ubuntu server with Ubuntu preloaded, the drivers should be able to be installed from the Driver Injection Disk in the factory.
5) When not preseeded, the customer should be offered the option to use the drivers on the Driver Injection Disk, with the default choice being No.

Revision history for this message
In , Matt (matt-redhat-bugs) wrote :

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

Revision history for this message
In , Jeremy (jeremy-redhat-bugs) wrote :

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

Revision history for this message
In , Matt (matt-redhat-bugs) wrote :

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.

Revision history for this message
In , Martin (martin-redhat-bugs) wrote :

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.

Revision history for this message
In , Martin (martin-redhat-bugs) wrote :

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

Revision history for this message
Mario Limonciello (superm1) wrote :

Attaching a patch to mountmedia. This changes it's behavior to define 3 types of driver disks:
1) Driver Disk (debs in ./)
2) Firmware Disk (debs in ./firmware)
3) Driver Injection Disk (debs in ./ubuntu/$(lsb_release -r -s)

Revision history for this message
Mario Limonciello (superm1) wrote :

Attaching bzr branch with changes to hw-detect.

This creates a new udeb to get loaded at install time that will check for driver injection disks.

Revision history for this message
Dustin Kirkland  (kirkland) wrote :

I've reviewed Mario's patches, and his approach.

I think this is a good design, and definitely something we would want to get into Jaunty.

This is going to be critical for Dell's support of Ubuntu on the server.

+1

:-Dustin

Revision history for this message
Matt Domsch (matt-domsch) wrote :

pointing at the public bug

Revision history for this message
Colin Watson (cjwatson) wrote :

It would be useful for this to be compatible with the driver update CD implementation already in casper, which uses /ubuntu-drivers/<kernel-version>/. I'd be happy to add the LSB release as a lookup alternative for casper, but /ubuntu-drivers/ was chosen to avoid confusion with Ubuntu CD images that already use /ubuntu/. Can we use /ubuntu-drivers/ instead?

The path should not be hardcoded, but should use DISTRIB_ID from /etc/lsb-release. localechooser has safe shell code for reading it.

I'm not sure I'm wild about the change to treat firmware disks separately. I agree that they're sort of different in some ways, but the delivery format is the same. Was this necessary for some particular reason not mentioned in the changelog entry?

I'm not sure about the new udeb in hw-detect. I'll need to look into this some more.

Colin Watson (cjwatson)
Changed in hw-detect (Ubuntu):
assignee: nobody → cjwatson
importance: Undecided → Wishlist
status: New → Triaged
Changed in mountmedia (Ubuntu):
assignee: nobody → cjwatson
importance: Undecided → Wishlist
status: New → Triaged
Revision history for this message
In , Martin (martin-redhat-bugs) wrote :

Should be present in anaconda 11.5.0.37

Jerone Young (jerone)
summary: - Add support for Dell Driver Injection Disk
+ [Feature Request] Add support for Dell Driver Injection Disk
Revision history for this message
In , Paniraj (paniraj-redhat-bugs) wrote :

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.

Revision history for this message
In , Martin (martin-redhat-bugs) wrote :

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

Changed in fedora:
status: Fix Released → In Progress
Revision history for this message
In , Bug (bug-redhat-bugs) wrote :

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

Revision history for this message
Mario Limonciello (superm1) wrote :

Hi Colin:

I've made the following changes, can you please review again:
 * Don't treat firmware disks as a separate case anymore
 * Pull the safe lsb-release reading code from localechooser in
 * Update name to be ubuntu-drivers/ instead of ubuntu/ per recommendation
 * Figure out the distribution by lsb-release as well (would theoretically allow debian-drivers too then for debian)

Revision history for this message
Mario Limonciello (superm1) wrote :

Ideally, would like to see these in 8.04.3 too for servers this year, but if that's not feasible, please re-target for 8.04.4.

Changed in mountmedia (Ubuntu Hardy):
importance: Undecided → Wishlist
milestone: none → ubuntu-8.04.3
Changed in hw-detect (Ubuntu Hardy):
importance: Undecided → Wishlist
milestone: none → ubuntu-8.04.3
Revision history for this message
Colin Watson (cjwatson) wrote :

Thanks, looks good now. The only change I'm making is that \L in a sed replacement expression is a GNU sed-ism, and not supportd by busybox sed, so won't work in the installer; I'm using tr 'A-Z' 'a-z' instead.

Revision history for this message
Colin Watson (cjwatson) wrote :

Oh, I'll also update the code in hw-detect to use block-attr rather than vol_id, as required in karmic.

Changed in hw-detect (Ubuntu Hardy):
milestone: ubuntu-8.04.3 → ubuntu-8.04.4
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package mountmedia - 0.19ubuntu1

---------------
mountmedia (0.19ubuntu1) karmic; urgency=low

  * Add support for looking for Dell Driver Injection disks, which store
    debs and udebs in $MNT/$(DISTRIB_ID)-drivers/$(DISTRIB_CODENAME). They're
    stored in this location so that the same driver disk can support multiple
    releases. (LP: #341526)

 -- Mario Limonciello <email address hidden> Fri, 28 Aug 2009 09:52:51 +0100

Changed in mountmedia (Ubuntu Karmic):
status: Triaged → Fix Released
Colin Watson (cjwatson)
Changed in mountmedia (Ubuntu Hardy):
milestone: ubuntu-8.04.3 → ubuntu-8.04.4
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package hw-detect - 1.72ubuntu4

---------------
hw-detect (1.72ubuntu4) karmic; urgency=low

  [ Colin Watson ]
  * Drop disk-detect/iscsi/enable template, which is no longer used.
  * Don't install mouseemu on Intel Mac desktops (LP: #251830).

  [ Mario Limonciello ]
  * Add support for Dell Driver Injection disk v1, an integrated flash media based
    solution for adding in drivers after OS launches. This feature will be on
    upcoming Dell servers. (LP: #341526)

 -- Colin Watson <email address hidden> Fri, 28 Aug 2009 09:59:27 +0100

Changed in hw-detect (Ubuntu Karmic):
status: Triaged → Fix Released
Brent Fox (brent-s-fox)
Changed in dell:
status: New → In Progress
Revision history for this message
Steve Langasek (vorlon) wrote :

Colin, Mario,

I see that this bug is fixed in karmic; can the fixes be backported to hardy and uploaded to the queue, for inclusion in 8.04.4? Or is that no longer a priority?

Revision history for this message
Steve Langasek (vorlon) wrote :

According to Mario, this is no longer a concern; declining for hardy.

Changed in hw-detect (Ubuntu Hardy):
status: New → Won't Fix
Changed in mountmedia (Ubuntu Hardy):
status: New → Won't Fix
Revision history for this message
In , Martin (martin-redhat-bugs) wrote :

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

Revision history for this message
Tony Espy (awe) wrote :

Based on Steve's comments above, I'm marking this as WontFix for the Dell project.

Changed in dell:
status: In Progress → Won't Fix
Changed in somerville:
status: New → Won't Fix
no longer affects: dell
Revision history for this message
Timothy R. Chavez (timrchavez) wrote :

The bug task for the somerville project has been removed by an automated script. This bug has been cloned on that project and is available here: https://bugs.launchpad.net/bugs/1305933

no longer affects: somerville
Changed in fedora:
importance: Unknown → High
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.