Bug 366341

Summary:	anaconda/kickstart - prompts on detecting read-only volumes even with ignoredisk
Product:	Red Hat Enterprise Linux 5	Reporter:	Dean Samuels <dsamuels>
Component:	anaconda	Assignee:	Anaconda Maintenance Team <anaconda-maint-list>
Status:	CLOSED INSUFFICIENT_DATA	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	5.0	CC:	clusterman, ddumas, jrfuller, rick.beldin, rproffit, va6ualei
Target Milestone:	---	Keywords:	Reopened
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-07-01 20:44:31 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:

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.

Johnray

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.