Bug 207331 - EDD support updates needed in RHEL5 Beta1
EDD support updates needed in RHEL5 Beta1
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: anaconda (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
: FutureFeature
Depends On:
Blocks: 184191
  Show dependency treegraph
Reported: 2006-09-20 14:40 EDT by Rezwanul Kabir
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version: 5.0.0
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-11-28 16:39:11 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Patch the solve EDD support issues in RHEL4 (5.68 KB, patch)
2006-09-20 14:40 EDT, Rezwanul Kabir
no flags Details | Diff
Modified patch per Jeremy's comments (4.89 KB, patch)
2006-09-22 12:29 EDT, Rezwanul Kabir
no flags Details | Diff

  None (edit)
Description Rezwanul Kabir 2006-09-20 14:40:37 EDT
Description of problem:

In the course of approximately past two years we, at Dell, have been 
extensively testing BIOS disk features in both our factory and Dell Server 
Assistant installations. So far we have discovered the following two issues. I 
have since ( from the time of RHEL4 Gold) created the attached patch for 
eddsupport.c to resolve them and till now we didn't find any more issues. 
Please consider the patch for inclusion in RHEL5 Beta2.   

  Issue 1: EDD code uses unique disk signatures to identify BIOS disks. In the 
offended code, anaconda would spit out error messages if it finds non-unique 
disk signatures for any set of disks in the system regardless of the fact that 
those BIOS disks are not actually referenced in ks.cfg. So, in case of DSA 
(Dell Server Assistant)installations , usually it just needs to find 
out "BIOSDISK 0x80" ( the first disk as seen by the bios) and doesn't care 
whether we can identify other "BIOSDISKS" or not( e.g biosdisk81, biosdisk 82 
etc). As long as the first biosdisk has unique signature we should be all 
right. But the offended code would bail out even if it CAN find biosdisk80 but 
CANNOT identify the others. So, the patch just makes sure that anaconda 
doesn't error out as long as it can find all biosdisks as referenced in 
ks.cfg.It doesn't care about the rest.. 

  Issue 2: If you have a USB floppy drive connected to the system during the 
install without a floppy in it, anaconda will error out failing to open the 
corresponding device file ( pls see at the end of this mail for the discussion 
thread I had with you regarding this).I changed the way -ENOMEDIUM was being 
handled and now the code that maps BIOS devices will ignore the -ENOMEDIUM 
error on trying to open a device file.

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


How reproducible:


Steps to Reproduce:

1.Do kickstart based install using BIOS disk feature
Actual results:

Install fails

Expected results:

Install should pass

Additional info:

 Attaching the patch to resolve the issues.
Comment 1 Rezwanul Kabir 2006-09-20 14:40:37 EDT
Created attachment 136763 [details]
Patch the solve EDD support issues in RHEL4
Comment 3 Jeremy Katz 2006-09-21 11:42:14 EDT
This patch introduces a couple of regressions at a glance:
* It doesn't ensure that /tmp/biosdev gets closed.  This will then lead to
errors later when doing partitioning
* I'm not sure it'll actually build with -Werror as you've removed the
assignment of the result from sscanf which raises a warning.

I'm also not sure that it's an okay generic assumption to make that duplicate
signatures are okay.  Some people do use the functionality for other BIOS disks
and I think it's important to not break that.  Why aren't you having unique sigs
across all the disks?
Comment 4 Rezwanul Kabir 2006-09-21 12:22:02 EDT
1. In Dell Server Assistant based installations, the customers usually do a 
reinstall of the OS. In this circumstances, the installer ensures that there 
is a unique signature for the biosdisk 0x80 but does not want to touch the 
rest of the disks so as to not corrupt any data/metadata on those. The idea 
is, since the installation will be done on the first BIOS disk and that is 
already ensured there is logically no reason to label others.

2. As I have mentioned in the description, as long as a user specifies a 
certain biosdisk ( say biosdisk 0x82 ) in the ks.cfg, and eddsupport.c can 
identify unique signature for that biosdisk, the install will go on otherwise 
it will error out.
Comment 5 RHEL Product and Program Management 2006-09-21 18:19:43 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux release.  Product Management has requested further review
of this request by Red Hat Engineering.  This request is not yet committed for
inclusion in release.
Comment 6 Jeremy Katz 2006-09-22 11:23:34 EDT
Okay, can you clean up the regressions I pointed out?
Comment 7 Rezwanul Kabir 2006-09-22 12:29:31 EDT
Created attachment 136950 [details]
Modified patch per Jeremy's comments

Jeremy, here you go..
Comment 8 Amit Bhutani 2006-10-02 19:53:01 EDT
Jeremy- Does the patch Rez submitted look good ?
Comment 9 Jeremy Katz 2006-10-03 16:55:18 EDT
It looks good, holding off until after branching from FC6 to add it as I'm just
not _quite_ comfortable changing that codepath at this point in the fc6 cycle
Comment 10 Jeremy Katz 2006-10-10 17:30:22 EDT
Committed to HEAD and rhel5-branch
Comment 11 Amit Bhutani 2006-11-03 01:58:21 EST
Rez- Can you please verify with the build we received from RH yesterday and post
results here ASAP so we can mark this as VERIFIED.
Comment 12 Rezwanul Kabir 2006-11-15 17:00:25 EST
Verified the patch in weekly build 2006-11-07. Thanks. This can be closed now.

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