Bug 504155
Summary: | Anaconda doesn't find/use the driver disc if on SATA device | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Larry Troan <ltroan> |
Component: | anaconda | Assignee: | Martin Sivák <msivak> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Release Test Team <release-test-team-automation> |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | 6.0 | CC: | borgan, bzeranski, ddumas, ichute, jcm, jturner, ltroan, mganisin, msivak, notting, syeghiay |
Target Milestone: | rc | Keywords: | Reopened |
Target Release: | 6.0 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | anaconda-13.21.47-1 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | 498048 | Environment: | |
Last Closed: | 2010-11-10 19:37:31 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: | 498048 | ||
Bug Blocks: |
Comment 1
RHEL Program Management
2009-06-04 14:15:21 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). * ************************************************************************** *** Bug 504534 has been marked as a duplicate of this bug. *** 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). This should work with the newest anaconda in rhel6. I was able to select driver disk iso image placed on SATA attached drive. Verified in RC3. Thanks 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. |