On Monday 05 July 2010, nodata wrote:
> On 06/07/10 01:30, Curtis Rempel wrote:
> > 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
>
> Can I ask why you are hardcoding this, and not determing which lun
> should do what based on logic (like "boot should go on the smaller lun")?
You raise a good question and the answer is: anaconda did it :-)
That is, the anaconda-ks.cfg template written after the initial manual
installation is what I based my kickstart development upon. That template
used the ondisk= syntax to specify either mpath0 or mpath1. In fact, I used
it several dozen times during kickstart development without incident. Only
when I presented new LUNs to the blade, did it fail by reversing the LUNs.
This was _unexpected_ behavior, especially since without multipathing, LUN 0
is always sda and LUN 1 is always sdb. Certainly I can write a bit of code
in %pre to figure out which is which, but the mystery remains as to why
things were reversed with the non-test LUNs and why re-creating the LUNs
reverted to the original expected behavior.
_______________________________________________
rhelv5-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/rhelv5-list
