Red Hat Bugzilla – Bug 207331
EDD support updates needed in RHEL5 Beta1
Last modified: 2007-11-30 17:07:34 EST
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):
Steps to Reproduce:
1.Do kickstart based install using BIOS disk feature
Install should pass
Attaching the patch to resolve the issues.
Created attachment 136763 [details]
Patch the solve EDD support issues in RHEL4
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?
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.
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.
Okay, can you clean up the regressions I pointed out?
Created attachment 136950 [details]
Modified patch per Jeremy's comments
Jeremy, here you go..
Jeremy- Does the patch Rez submitted look good ?
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
Committed to HEAD and rhel5-branch
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.
Verified the patch in weekly build 2006-11-07. Thanks. This can be closed now.