Bug 207331

Summary: EDD support updates needed in RHEL5 Beta1
Product: Red Hat Enterprise Linux 5 Reporter: Rezwanul Kabir <rezwanul_kabir>
Component: anacondaAssignee: Jeremy Katz <katzj>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 5.0CC: wwlinuxengineering
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: pm-20060928
Fixed In Version: 5.0.0 Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-11-28 21:39:11 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:    
Bug Blocks: 184191    
Attachments:
Description Flags
Patch the solve EDD support issues in RHEL4
none
Modified patch per Jeremy's comments none

Description Rezwanul Kabir 2006-09-20 18:40:37 UTC 
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):

anaconda-11.1.0.77

How reproducible:

Always

Steps to Reproduce:

1.Do kickstart based install using BIOS disk feature
2.
3.
  
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 18:40:37 UTC 
Created attachment 136763 [details]
Patch the solve EDD support issues in RHEL4
Comment 3 Jeremy Katz 2006-09-21 15:42:14 UTC 
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 16:22:02 UTC 
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 Program Management 2006-09-21 22:19:43 UTC 
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 15:23:34 UTC 
Okay, can you clean up the regressions I pointed out?
Comment 7 Rezwanul Kabir 2006-09-22 16:29:31 UTC 
Created attachment 136950 [details]
Modified patch per Jeremy's comments

Jeremy, here you go..
Comment 8 Amit Bhutani 2006-10-02 23:53:01 UTC 
Jeremy- Does the patch Rez submitted look good ?
Comment 9 Jeremy Katz 2006-10-03 20:55:18 UTC 
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 21:30:22 UTC 
Committed to HEAD and rhel5-branch
Comment 11 Amit Bhutani 2006-11-03 06:58:21 UTC 
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 22:00:25 UTC 
Verified the patch in weekly build 2006-11-07. Thanks. This can be closed now.