Hide Forgot
Created attachment 473488 [details] Screen shot Description of problem: When installing RHEL6.0 with a DUD that contains the OEMDRV label for DUD autodetection, the DUD is read automatically. This happens very quickly and silently, so that most users don't realize that the DUD is already loaded. Later on, loader opens a pop-up "Do you have a driver disk?". It is correct to respond "no" there, but users don't realize this and respond "yes", trying to load the same DUD again. This causes an error message "no devices of appropriate type were found on this driver disk" (see attached screen shot). This error message makes users believe that there is something wrong with the driver disk. Version-Release number of selected component (if applicable): 13.21.82-1.el6 How reproducible: Always Steps to Reproduce: 1. Install using DUD supporting DUD autodetection with OEMDRV label 2. Manually load driver disk when prompted Actual results: "no devices of appropriate type were found on this driver disk" Expected results: A more adequate message, e.g. "this driver disk has already been loaded". Also, when the autodetected DUD is found, an informational pop-up "loading driver disk XYZ..." would be helpful. Additional info: This problem has been known at Fujitsu for a long time. I thought it could be handled by just explaining that the DUD is being auto-loaded and that the error message displayed is misleading. However I am getting repeated reports of "broken" DUDs which are just caused by this message. Please fix for 6.1, if possible.
Opened support case 00402545 to track this.
What we can do (and we were planning to do it anyways) is to backport the confirmation dialog from RHEL5.5 oemdrv code. Then you would have to confirm, that you want to load the autodetected driverdisk. The second question will be shown too, but hopefully there would be less confusion. We could alter the wording a bit too to "Do you have any unapplied driverdisk?" or similar. What do you think?
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
(In reply to comment #3) > What we can do (and we were planning to do it anyways) is to backport the > confirmation dialog from RHEL5.5 oemdrv code. Then you would have to confirm, > that you want to load the autodetected driverdisk. I am not sure about this. I think the automatic loading is a good thing. For me it would be sufficient if an informational pop-up requiring no confirmation would be displayed for a few seconds. However, if this is the easiest way for you, I have no objections. > The second question will be > shown too, but hopefully there would be less confusion. We could alter the > wording a bit too to "Do you have any unapplied driverdisk?" or similar. > > What do you think? That sounds good. Moreover, the "no devices of the appropriate type" .... message should be modified, e.g. like this: "No new drivers were found on this driver disk. This may indicate that this disk has already been loaded, or that the drivers it contains don't match your hardware". Ideally, at this point and/or in the preceding dialog, loader would display a how many DUDs were already loaded successfully, either manually or automatically. That would make users understand that their DUD was already loaded.
There is no real difference between showing info or confirmation dialog for me, but the confirmation was requested by security people. The wording can be changed, but the DD count would require a bit bigger change to code (well or a nasty hack which I do not want to do for maintainability reasons of course). We still have to get this approved by management, but it should be no problem. I'll get back to you once it is testable.
Will be included in anaconda-13.21.91-1
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2011-0530.html