Several months ago, I developed a kickstart for an IBM blade attached to a
DS4300 SAN. Launching kickstart with the "mpath" parameter would build the
machine properly. LUN 0 is 16 GB and LUN 1 is 100 GB. These would correctly
show up as /dev/sd{a,c} and /dev/sd{b,d} respectively along with their
multipath devices, mpath0 for LUN 0 and mpath1 for LUN 1.
So far so good.
Today I booted the same blade with the same unmodified kickstart but presented
two other identically sized LUNs to it instead (removing the original LUNs
first). Things didn't go as expected and closer inspection revealed that
mpath0 was pointing to /dev/sd{c,d} and mpath1 was pointing to /dev/sd{a,c} -
the reverse of what it should be. I confirmed this with Alt-F2 during
installation and using "multipath -l". Booting into rescue showed the same
thing. Either way, /dev/sd{a,c} was correctly pointing to the 16 GB LUN (LUN
0) and /dev/sd{b,d} was correctly pointing to the 100 GB LUN (LUN 1). Just
the mpath devices were backwards and so the bootloader would be installed on
mpath0, the opposite of the BIOS, and thus it would fail to boot.
After much head scratching, I decided to delete and recreate these two LUNs.
The kickstart proceeded to work this time, using mpath0 for /dev/sd{a,c} and
mpath1 for /dev/sd{b,d}.
These seems bizarre. Why would deleting and recreating these LUNs cause it to
work?
It seems that bugzilla 502768 is an enhancement to 5.5 that allows kickstart
to specifiy the root LUN in an mpath config. I don't know if that is related
to this scenario or not.
Thanks for any help anyone can provide on this!
Curtis
_______________________________________________
rhelv5-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/rhelv5-list
