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:
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.
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
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.
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.
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.
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.
It has not yet been released.
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.
Yes, we have a TAM. I've opened a case and asked him to look into getting me this release to test.
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.