RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 504155 - Anaconda doesn't find/use the driver disc if on SATA device
Summary: Anaconda doesn't find/use the driver disc if on SATA device
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: anaconda
Version: 6.0
Hardware: All
OS: Linux
medium
high
Target Milestone: rc
: 6.0
Assignee: Martin Sivák
QA Contact: Release Test Team
URL:
Whiteboard:
: SataCD (view as bug list)
Depends On: 498048
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-06-04 14:01 UTC by Larry Troan
Modified: 2016-04-18 09:47 UTC (History)
11 users (show)

Fixed In Version: anaconda-13.21.47-1
Doc Type: Bug Fix
Doc Text:
Clone Of: 498048
Environment:
Last Closed: 2010-11-10 19:37:31 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Comment 1 RHEL Program Management 2009-06-04 14:15:21 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

Comment 2 Larry Troan 2009-06-05 15:23:26 UTC
Removing confidential information and opening this bug to the public because it may affect multiple hardware vendors and customers.....

+++ This bug was initially created as a clone of Bug #498048 +++ 
 +++ which was closed as WONTFIX for RHEL5.4 because the fix +++
      +++ is highly invasive and there are workarounds +++

Description of problem:
The "dd" parameter in the initial anaconda command line input "linux dd" or
"linux askmethod dd" is ignored unless a network install is specified.

Though I suspect this is an attempt to prevent a customer from going down the
wrong path during installation, it prevents the use of DUD (Driver Update Disk) to fix a critical problem with an older RHEL provided driver.

In conjunction with a physical media installation, the network driver can be installed "post install" but it may be crucial to overlay the shipping driver with a DUD containing a critical fix. With the current 5.3 anaconda logic, this is not possible.


Version-Release number of selected component (if applicable):

How reproducible:
Install RHEL5.3 on a system using physical media (CD/DVD) where there is a network driver requiring a DUD.

Steps to Reproduce:
1. Burn 5.3 DVD (x86_64 or x86).
2. At anaconda prompt, specify "linux dd" or "linux askmethod dd"
3. Install completes without installing the driver contained on the DUD 
   leaving the network unreachable. 
4. Insert the DUD after firstboot and install the new driver
   via an "rpm -ivh driver.name."
5. Reboot the system (driver is now properly installed)

Actual results:
Network unreachable after install until post-install of DUD driver as above

Expected results:
Customer is prompted for the DUD during installation and the new driver is
installed as part of that installation -- not afterwards.

Additional info: 
The concern is that if an updated driver is provided via a DUD to fix a
significant problem such as a critical security errata or data corruptor, the
fix can not be made until after the installation is complete.

Also, I assume that if the DUD contains a driver to access the HD and the
customer specified "linux dd" that anaconda will request the DUD. Note that video and audio drivers can not be installed as part of the DUD process and must be installed after the installation completes.

--- Additional comment from jturner on 2009-04-28 15:23:36 EDT ---

Summarizing a bit, when 'dd' is passed on the command line, anaconda will only
attempt to load drivers for the chosen installation method.

--- Additional comment from jturner on 2009-04-29 09:04:24 EDT ---

Actually I thought about this some more, as well as chatted with jlaska and I
think the right thing to do in this case is add the driver disk as a repository
in the package selection screen.  That would allow for the installation of the
driver RPM as part of the installation as opposed to the risk of bringing up
the entire network stack when it's not necessary.

--- Additional comment from jturner on 2009-05-01 10:14:52 EDT ---

And some more thoughts on the matter.  Larry convinced me to look at the forest
instead of just the trees.

Consider these two examples:

1) You have a box with an adapter (either storage or network, pick your
favorite.)  The distro driver for that adapter has a defect which can result in
data corruption.  We decide to override with a driver update in order to
resolve the data corruption defect.  Current behavior in RHEL5.3 won't allow
this, even when booting with "linux dd" as anaconda will load the driver for
the storage/network adapter and move on without ever pulling in the driver
update (because there are drivers in the distro for the adapters.)  It appears
that anaconda will only attempt to pull in driver updates in the case where it
can't find a distro driver for the equipment necessary to complete the install
via the requested method.

2) You have a box with 2 different adapters (again, either storage or network,
doesn't matter) which require different drivers, one of which is shipped in the
distro.  But you need to use the "unsupported" adapter in order to complete the
install (you need to use the 10GigE adapter as that's on the network where the
distro is shared, for example current behavior, you boot with "linux dd" and
indicate you wish to perform a network installation.  Anaconda will load up the
driver for the recognized network adapter, be satisfied and move on without
ever loading up the driver update.

Certainly the second case is far more likely than the first, but both are
rooted in the fact that anaconda tries to outsmart the user when it should at
least read-in and give the user the opportunity to utilize the updated drivers
no matter what drivers are found in the distro.

--- Additional comment from jcm on 2009-05-01 16:47:08 EDT ---

I should add that I've not seen this bug in KVM-based "local CD" testing of
e.g. 5.3 Anaconda installs. So something has changed or is unique to Larry's
setup. Either way, Anaconda is trying to be too smart - if we say "dd", we
always mean use a driver disk. There could be any number of reasons why we need
one and the last thing we need is for Anaconda to try to outsmart our reasoning
:)

--- Additional comment from msivak on 2009-05-13 10:30:03 EDT ---

I just can't reproduce this on my machine. I burned the RHEL 5.4 Client DVD
(yesterdays nightly) and used the "linux dd" command. The first dialog I
encounter is the question whether I have driver disk.

Can you still reproduce this bug? And are there any special reproduction steps?

--- Additional comment from jturner on 2009-05-13 11:26:34 EDT ---

Boot the machine with 'linux dd' as you did and sure enough, you'll get
prompted if you have a driver disk.  The issue is that, even after an
affirmative reply, anaconda will only prompt for that driver disk if there are
no drivers available for the selected installation method.  So in your case
(booting with a DVD) that would mean there wasn't a valid storage driver found
on the system.

Or try this example (real-world . . . just tried it on a test box sitting at my
desk.)  This system has 2 network cards, one is an e1000 and the other is a
brand-new Intel card that we don't include a driver for in 5.4.  I boot up with
"linux dd" and get the prompt asking if I have a driver disk.  I reply "Yes"
then get prompted for the installation method and I choose "NFS."  At that
point the network configuration screen comes up.  I'm never prompted to insert
my driver disk because anaconda found a valid networking device and a valid
storage driver.  What if I wanted to use the "new" Intel NIC for the
installation?  Or worse, what if there were a bug with the e1000 driver and I
wanted to us an updated e1000 driver for the installation?  I don't get that
option.

That's one issue.  The second issue is how should a customer apply a driver
update for a driver which isn't utilized during installation?  Say in the case
of a CD-based installation where the network driver needs to be updated?  It
appears that case should be handled by adding a repository during package
installation, but I'm not sure that actually works (haven't tried) and I'm not
sure how a customer would instruct anaconda that the repo were on a CD (again,
haven't tried.)

--- Additional comment from jturner on 2009-05-14 07:24:27 EDT ---

New findings!

1) On a machine with a single CD/DVD drive, I booted from CD with 'linux dd'
and at the prompt asking if I have a driver disk, I ejected the OS CD, inserted
the driver disk and then clicked "Yes."  I get the message, "no devices found
to load drivers from" in the log.  So it appears that anaconda is excluding the
CD/DVD drive from the detection routine.
2) I tried the scenario again but used a USB thumb drive for the driver disk
and all worked as expected.  Answering "Yes" to the driver disk question
results in loading up of the drivers and the dialog asking if I have other
driver disks I wish to load.

So appears we just have the problem with booting from CD and then using a
CD-based driver disk.

--- Additional comment from notting on 2009-05-19 10:49:25 EDT ---

How is the CD drive attached?

--- Additional comment from jturner on 2009-05-19 11:52:18 EDT ---

SATA.  Bill, the machine is here at my desk if you care to lay hands on.

--- Additional comment from notting on 2009-05-19 11:59:22 EDT ---

There's no SATA/libata drivers loaded yet. So it won't see the CD-ROM at this
point.

I suspect fixing this would require reordering parts of anaconda, which may be
problematic.

--- Additional comment from notting on 2009-05-19 12:07:09 EDT ---

Re, comment #5: it's possible that JCM didn't see this in 5.3 w/KVM because it
would be using the ide-cd driver under KVM. Whether or not it sees the driver
disk at this point would depend on whether or not it needs an additional
storage driver to see the device.

--- Additional comment from jturner on 2009-05-19 13:53:13 EDT ---

So guess the summary of this BZ should really be, "Anaconda isn't able to load
driver disk from SATA devices."

--- Additional comment from notting on 2009-05-19 15:12:04 EDT ---

Or SCSI, etc. (Not that there are likely many SCSI CD-ROMs out there at this
point.)

--- Additional comment from msivak on 2009-05-20 03:53:28 EDT ---

Bill, isn't usb-storage emulated through scsi layer too? The lsmod screenshots
list some scsi modules.

But obviously we have a chicken and egg problem again.. we cannot load sata
modules before driver disks are processed, because we are not able to replace
loaded module with newer version.

--- Additional comment from jturner on 2009-05-20 06:59:17 EDT ---

Re; comment 23 . . . that's probably a question for the EPM team.  I think we
have two issues to contend with:

1) Most (if not all) of the CDROM drives shipping in today's hardware are
attached to SATA controllers.  Thus as presently coded, there's no way to
replace/add-in the storage drivers using a CD-based driver disk.
2) It is possible to use a CD-based driver disk to replace/add-in network
drivers, but it's a bit convoluted, and will only work in the case where the
customer is performing a network-based installation and there are no valid
network drivers available.

The good news is that everything appears to work just fine with either USB
drive-based driver disks or network retrieval of the driver disk.  But that
still leaves the question for the EPM team.  What distribution method are the
partners planning on utilizing?  In the most recent case I was involved, the
partner was planning on dropping a CD-based driver disk in the box.

Honestly at this point I'm afraid to monkey around with the anaconda logic too
much and would instead prefer we put cycles into improving the
documentation/kbase/etc. around driver disk usage.

--- Additional comment from notting on 2009-05-20 11:04:15 EDT ---

(In reply to comment #24)
> Bill, isn't usb-storage emulated through scsi layer too? The lsmod screenshots
> list some scsi modules.

See the call to usbInitialize in loader.c; we explicitly load usb-storage
whenever there's a USB adapter.

--- Additional comment from msivak on 2009-05-21 10:04:25 EDT ---

We can't fix this bug as we have to revise our policy about loading modules and
driver disc updates first. To load the drivers from SATA cdrom, more storage
drivers are needed, but at the same time, driver discs are usually used to
update the storage drivers in question.

Since usb storage devices and network retrieval are supported methods of
putting updated drivers into the installation environment, we will revise and
clarify the documentation about this matter.

--- Additional comment from msivak on 2009-05-22 04:35:39 EDT ---

John, linux dd always asks for the driver disc and let you select the source if
there are more devices capable of holding it. However, if you have only one
possible source than it tries to use that one and if you have none, there is
really nothing to do.

**************************************************************************
* The whole issue was reduced to: It doesn't find/use the driver disc if *
* it is stored on SATA device (because SATA is not loaded at the time).  *
**************************************************************************

Comment 3 Bill Nottingham 2009-06-10 19:51:48 UTC
*** Bug 504534 has been marked as a duplicate of this bug. ***

Comment 4 Martin Sivák 2010-02-03 11:42:45 UTC
We have new driver disc code present in RHEL6 and we are waiting for the other pieces to get there as well. When they do, we will be able to test it (the environment differs from RHEL5 a lot as we are using udev instead of kudzu now).

Comment 5 Martin Sivák 2010-05-26 11:13:28 UTC
This should work with the newest anaconda in rhel6.

Comment 14 Marian Ganisin 2010-09-23 10:55:44 UTC
I was able to select driver disk iso image placed on SATA attached drive. Verified in RC3.

Comment 15 Jon Masters 2010-09-24 17:55:33 UTC
Thanks

Comment 16 releng-rhel@redhat.com 2010-11-10 19:37:31 UTC
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.


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