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")?
_______________________________________________ rhelv5-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/rhelv5-list
