Bug 654444 - ignoredisk statement behaviour has changed in RHEL6
Summary: ignoredisk statement behaviour has changed in RHEL6
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: anaconda
Version: 6.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Anaconda Maintenance Team
QA Contact: Release Test Team
Depends On:
TreeView+ depends on / blocked
Reported: 2010-11-17 21:21 UTC by Gerardo Arceri
Modified: 2010-12-01 16:11 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-11-18 22:13:19 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Gerardo Arceri 2010-11-17 21:21:06 UTC
Description of problem:

Until RHEL5.5: an statement like this on ks.cfg used to work
ignoredisk --drives=md0,sdb,sdc,cciss/c0d1

Even when any of the disk didn't exist.
This allowed us to have a common generic ks profile for all hardware platforms.
Same problem when using the --only-use parameter.

ON RHEL6 anaconda complains and aborts in case any of the disk listed are missing.

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

How reproducible:

Steps to Reproduce:
1. Modify ks.cfg to include a statement like ignoredisk --drives=md0,sdc,cciss/c0d1
2. Kickstart a system using that kickstart file
3. wait until anaconda complies about a missing disk and aborts with a #Works as long as all the listed disks are present, if any of them is missing it anorts with a "Disk XXXXXX missing" message and asks to press CTRL-C or C-A-Del to reboot.
Actual results:
Anaconda fails indicating that a disk in the ignoredisk statement are missing

Expected results:
if there is any good reason to keep this behaviour it should have been documented in the release notes, otherwise i think that its behaviour should be restore to the one in RHEL5.5.

Additional info:

Comment 2 Chris Lumens 2010-11-17 21:27:18 UTC
This is documented in the migration guide:


Comment 3 peter.sjoberg 2010-11-18 18:09:26 UTC
So what is the reason to fail when a ignored disk is not found ? I see no value-add in requiring a ignored disk to exist. 

Adding things like 
  ignoredisk --drives=/dev/disk/by-path/pci-0000:0f:00.0-scsi-0:0:0:2
or even
  ignoredisk --drives=/dev/disk/by-path/pci-0000:0f:00.0-scsi-0:0:1:*
fails just as bad as --drives=sdb when there is no :2 disk

Comment 4 David Cantrell 2010-11-18 22:13:19 UTC
As explained on the page linked to from comment #2:

"Kickstart will halt with an error in more cases than previous versions. For example, if you refer to a disk that does not exist, the installation will halt and inform you of the error. This is designed to help detect errors in Kickstart files before they lead to larger problems. As a side-effect, files that are designed to be generic across different machine configurations may fail more often. These should be dealt with on a case-by-case basis."

If would like some help updating your kickstart file for RHEL 6.0, see the Kickstart documentation as well as the Migration Guide for RHEL 6.0.

Comment 5 Mark Ostroski 2010-11-19 17:56:58 UTC
I agree with Peter and Gerardo.  For RHEL5 kickstart builds I have relied on ignoredisk and nousbstorage to ensure that my USB Installation media is not wiped out by the clearpart --all directive, while permitting the same unmodified ks.cfg file to work if I chose to use CD/DVD installation media with no USB attached.

I don't agree with the logic for outright failure if a wildcard specification for ignoredisk does not match.  I understand the point made in the documentation that this is to prevent the possibility that an error in the ignoredisk specification could lead to other errors.  However, I feel that this unreasonably limits some perfectly valid configuration scenarios for system administrators.

I propose that an option be added to the ignoredisk directive to explicitly allow a no-match scenario to proceed without error, e.g: ignoredisk --drives=/dev/disk/by-path/pci-*-usb-* --allow-nomatches

By allowing the "no match" case to be explictly permitted, you would give more flexibility to system administrators to do what works best for them.  

For what it's worth, I've worked around my problem using a %pre script to unload the usb_storage module, however such a workaround might not be possible in other scenarios.

If you need another example: I have also frequently done builds where I need to ensure that the kickstart config ONLY wipes out and uses the first disk array on a system, where a system may or may not have multiple arrays configured.  Again, it would be extremely beneficial to me to be able to use a generic kickstart config that ignores the second array IF it exists, but also proceeds successfully if it does not.  That way I don't have to deal with the inevitable situation where I accidentally wipe out a disk array by using the wrong kickstart configuration for that particular hardware.  I haven't gotten this far yet but maybe I can come up with a creative %pre script to address this.  Maybe I will find --only-use to be sufficient.  There is certainly value in having a simplified configuration available in the kickstart configuration options, as was previously available in RHEL5.

Also, for what it's worth, the Migration Guide is very helpful explaining the new behavior but it seems that the Installation Guide should also explain this behavior.

Thanks for your consideration!

Comment 6 peter.sjoberg 2010-12-01 16:11:53 UTC
So as I understand this we have a few options
1 - have exactly the same hardware every where or have a specific ks.cfg for every server
2 - run a %pre script that checks if md0 is around and only then add it to the ignore list (that's assuming %pre isn't to late in the overall disk discovery)
3 - forget about ignore disk all together and handle the disk in %pre

1 - I don't see that in any place where you have more then one server (at what point you don't need kickstart anyway)
2 & 3 - why is there even an option to exclude a disk if I have to figure out everything my self first ?

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