Bug 366341 - anaconda/kickstart - prompts on detecting read-only volumes even with ignoredisk
Summary: anaconda/kickstart - prompts on detecting read-only volumes even with ignoredisk
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: anaconda
Version: 5.0
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: Anaconda Maintenance Team
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2007-11-05 03:17 UTC by Dean Samuels
Modified: 2010-07-01 20:44 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-07-01 20:44:31 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Dean Samuels 2007-11-05 03:17:47 UTC
Description of problem:
Client is attempting to kickstart RHEL5 to a blade system with SAN attached
storage.  The customer is hitting an issue where anaconda complains with the
following message at the beginning of the install:

On virt console 1:
Warning: /dev/sda is a read-only filesystem and hit OK to continue

On virt console 3:
  parted exception: Warning: Unable to open /dev/sda read-write
(Read-only file system).  /dev/sda has been opened read-only

The customer has to hit OK to accept this and the installation will then
complete successfully.

There are currently two LUNs presented from the SAN to the host.  /dev/sda is
indeed read-only and apparently it is a gatekeeper type device that is
exported/presented to numerous hosts hence why it's read-only.  /dev/sdb is the
second LUN device that we want to install to.

I've tried using the following entries in the kickstart file:
  ignoredisk --drives=sda
  clearpart --all --drives=sdb
  partition /boot --fstype=ext3 --size=200 --ondisk=sdb
  partition pv.03 --size=1 --grow --ondisk=sdb
 <and create vg and lv......>

And removing the zerombr reference but the customer is still hitting the issue.

How reproducible:
1. Install via kickstart or manual
2. Kickstart profile uses 'ignoredisk=sda' to ignore first LUN
3. Still prompted by anaconda that sda is read-only
4. Hitting Ok or Ignore will continue the installation
Version-Release number of selected component (if applicable):

Steps to Reproduce:
1. Install via kickstart or manual
2. Kickstart profile uses 'ignoredisk=sda' to ignore first LUN
3. Still prompted by anaconda that sda is read-only
4. Hitting Ok or Ignore will continue the installation
Actual results:
User prompted to hit OK when /dev/sda device is found to be read-only

Expected results:
ignoredisk directive in kickstart should indicate which devices to ignore and
not present a warning that it's read-only.

Additional info:

Comment 1 Chris Lumens 2008-04-18 12:29:26 UTC
The problem here is that we still scan the drives to attempt to determine which
filesystem labels are in use and which bootloader config options to present to
the user.  Even though we're not really going to write anything to them, we
still need to read data from the ignored disks.

ignoredisk really only refers to that certain disks should not be used when
creating partitions and clearing devices.

Comment 2 Johnray Fuller 2009-03-12 00:22:32 UTC
But do you have to post a "Read Only Disk" error for each one you come across that's read only? What if you have a SAN with hundreds of "read-only" LUNs? How can you automate that if you have to be on the console to click "OK" one hundred times?

Maybe ignoredisk isn't the right parameter to deal with this, but *something* needs to.


Comment 3 Chris Lumens 2009-03-31 19:58:41 UTC
I notice this is a RHEL5 bug, but not one with a corresponding IT score.  Is there a chance we can pursue this as a Fedora bug and once it's fixed up, close as NEXTRELEASE due to it being in RHEL6?

I ask because I committed a patch today that should make ignoredisk work the way it should, and the way this bug report wants.  However, it could use some testing.  If you could test against rawhide (not F11 beta - patch is not there) and provide feedback, it would be very helpful in making sure we no longer have this problem going into RHEL6.  Thanks.

Comment 6 Greg A 2009-05-05 19:26:03 UTC
Is there any work around other than waiting until the next release of RHEL?  We need a fix for this now.  We have over 50 servers to upgrade to RHEL5.  This bug stops us from doing our kickstarts. Ultimately, we need an option to ignore SAN that works on HP, IBM, Dell, etc.  It should not matter which HBA we use either.

Comment 7 Chris Lumens 2009-05-05 19:33:35 UTC
Next major release, or next update release?  I believe the fix for bug 455465 may also help fix up this issue, and that's scheduled to be a part of the next update release to RHEL5.  If it is at all possible for you to test the 5.4 beta when it is released, that would help clarify whether this bug is also taken care of.  If not, we will have to decide how to proceed with this bug report.

Comment 8 Greg A 2009-05-05 19:43:50 UTC
You mentioned RHEL6.  We can't wait for RHEL6.  I would be happy to test this immediately if you can point me to 5.4 beta.

Comment 9 Chris Lumens 2009-05-05 19:53:16 UTC
It has not yet been released.

Comment 10 Denise Dumas 2009-05-05 21:39:35 UTC
Greg, the 5.4 code freeze is next Thursday. We typically create a relatively-untested Alpha and sanity-check it internally, apply bugfixes, and that is what becomes the Beta. Does your company have a TAM? If so, we can maybe get the Alpha to him/her as we do with our hardware partners.

Comment 11 Greg A 2009-05-06 13:37:13 UTC
Yes, we have a TAM.  I've opened a case and asked him to look into getting me this release to test.

Comment 12 Denise Dumas 2009-06-30 20:33:52 UTC
Moving to RHEL 5.5 so it doesn't get mistakenly closed by the bot. But the Beta is now available - Greg, Robert Proffitt should be able to get it for you.

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