Bug 517787 - Kickstart install of diskless HP BL465c G1 fails when two FC LUNs are present
Summary: Kickstart install of diskless HP BL465c G1 fails when two FC LUNs are present
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: anaconda
Version: 5.3
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Anaconda Maintenance Team
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-08-17 08:07 UTC by Nik Lam
Modified: 2011-06-29 14:32 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-08-27 12:30:40 UTC


Attachments (Terms of Use)

Description Nik Lam 2009-08-17 08:07:46 UTC
Description of problem:
Kickstart install onto diskless HP BL465c G1 blade server with two 100GB fibre-channel SAN LUNs presented fails on reboot with 

fsck.ext3: No such file or directory while trying to open /dev/mapper/mpath0p1 /dev/mapper/mpath0p1:
The superblock could not be read or does no describe a correct ext2 filesystem. [ ... snip]

This problem does not occur when the install is done manually from DVD media.

A kickstart install does work if the second LUN is not presented to the blade, leaving the system with only a single LUN.


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


How reproducible:
Consistent.


Steps to Reproduce:
1. Ensure that the FC HBA settings on the blade allow the two LUNs to be seen by the isolinux installer. Boot from isolinux-based install media using the mpath kernel parameter to launch a kickstart install. The kickstart file is sourced from an RHN Satellite Server. The disk partitioning settings in the kickstart are as follows

zerombr yes
clearpart --all
part /boot --fstype=ext3 --size=200 --asprimary
part pv.01 --size=10000 --grow
volgroup sys pv.01
logvol --vgname=sys swap --name=swap --size=1 --recommended
logvol / --fstype=ext3 --vgname=sys --name=rootlv --size=2000 --grow --maxsize=4000
logvol /home --fstype=ext3 --vgname=sys --name=homelv --size=2000 --grow --maxsize=4000
logvol /tmp --fstype=ext3 --vgname=sys --name=tmplv --size=500 --grow --maxsize=1000
logvol /usr --fstype=ext3 --vgname=sys --name=usrlv --size=2000 --grow --maxsize=4000
logvol /var --fstype=ext3 --vgname=sys --name=varlv --size=2000 --grow --maxsize=4000
bootloader --location mbr

2. Allow the install to complete sucessfully
3. Let the system reboot from the LUN.
  
Actual results:
fsck.ext3: No such file or directory while trying to open /dev/mapper/mpath0p1 /dev/mapper/mpath0p1:
The superblock could not be read or does no describe a correct ext2 filesystem. [ ... snip]

The system then allows you, with root password authentication, into an emergency recovery shell.

Expected results:
System boots normally.

Additional info:
Looking around at the system from the recovery shell, we are able to get the system into runlevel 3 through the following steps

(i) mount -o remount,rw /
(ii) mount -a (which produces an error)
(iii) umount /var , /usr , /tmp (each of which produced errors, but did successfully unmount the pseudo-filesystems)
(iv) mount -a  
(v) service multipathd start
(vi) mount -a (to mount /boot)
(vii) init 3

I don't yet have good details of the SAN infrastructure, as it is managed outside my immediate organisation. I believe the LUNs are physically on an HP EVA8000 behind an IBM storage virtualisation system called SVC. From what I have heard the EVA8000 operates in active-active mode, but the SVC only operates in active-passive failure mode.

I have logged a support request (1937078), in the hope of getting a temporary workaround; perhaps through some further documentation of the "multipath --rule=" kickstart parameter. There are some sosreports of the system in various states in that job.

Searching bugzilla for "/dev/mapper/mpath0p1" does present several similar sounding bugs, but I couldn't spot any where the problem existed only when more than a single LUN was presented.

Comment 1 Nik Lam 2009-08-27 00:58:12 UTC
Following assistance from Red Hat support, we settled on the following partitioning scheme in our kickstart file:

#=============

partition /boot --fstype ext3 --size=100 --ondisk=mapper/mpath0
partition pv.01 --size=10000 --grow --ondisk=mapper/mpath0

volgroup sys pv.01

logvol --vgname=sys swap --name=swap --size=1 --recommended
logvol / --fstype=ext3 --vgname=sys --name=rootlv --size=2000 --grow --maxsize=4000
logvol /home --fstype=ext3 --vgname=sys --name=homelv --size=2000 --grow --maxsize=4000
logvol /tmp --fstype=ext3 --vgname=sys --name=tmplv --size=500 --grow --maxsize=1000
logvol /usr --fstype=ext3 --vgname=sys --name=usrlv --size=2000 --grow --maxsize=4000
logvol /var --fstype=ext3 --vgname=sys --name=varlv --size=2000 --grow --maxsize=4000

#=============

The use of --ondisk=mapper/mpath0 appended to the "partition" directives did the trick.

This can be closed as NOTABUG.

Comment 2 Denise Dumas 2009-08-27 12:30:40 UTC
Thanks for letting us know.


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