Using onbiosdisk and labels to overcome disk ordering problems?

Chad Metcalf chad at cloudera.com
Tue Dec 1 05:38:23 UTC 2009


We're using dual disk controller systems with 12 drives. Booting from
a usb key and using a http ks.cfg and NFS mounted centos 5.4 disk
image. We're trying to avoid the problem mentioned here:
linux.dell.com/installermagic.shtml (basically If you have multiple
disk controllers, and multiple disks, in your system, it can happen
that BIOS discovers disks in one order, but the Linux OS discovers
them in a different order.)

I don't care what drive partitions go on. So long as every drive is
partitioned and mounts to the same place each boot.

I thought that using --onbiosdisk and --labels would achieve this.
First by walking through all the disks starting with the boot disk.
Then by using labels that would get pulled into fstab.

I'm using a %pre script to include a partition table which I've
captured the output of:

clearpart --linux --initlabel
--drives=sda,sdb,sdc,sdd,sde,sdf,sdg,sdh,sdi,sdj,sdk,sdl
part /boot --fstype ext3 --size=100 --onbiosdisk=80 --label=/boot
part / --fstype ext3 --size=10240 --onbiosdisk=80 --label=/
part swap --size=12288 --onbiosdisk=80 --label=swap
part /data1/state --fstype ext3 --size=476160 --grow --onbiosdisk=80
--label=/data1/state
part /data1/scratch --fstype ext3 --size=100 --grow --onbiosdisk=80
--label=/data1/scratch
part /data2/state --fstype ext3 --size=476160 --onbiosdisk=81
--label=/data2/state
part /data2/scratch --fstype ext3 --size=100 --grow --onbiosdisk=81
--label=/data2/scratch
part /data3/state --fstype ext3 --size=476160 --onbiosdisk=82
--label=/data3/state
part /data3/scratch --fstype ext3 --size=100 --grow --onbiosdisk=82
--label=/data3/scratch
part /data4/state --fstype ext3 --size=476160 --onbiosdisk=83
--label=/data4/state
part /data4/scratch --fstype ext3 --size=100 --grow --onbiosdisk=83
--label=/data4/scratch
part /data5/state --fstype ext3 --size=476160 --onbiosdisk=84
--label=/data5/state
part /data5/scratch --fstype ext3 --size=100 --grow --onbiosdisk=84
--label=/data5/scratch
part /data6/state --fstype ext3 --size=476160 --onbiosdisk=85
--label=/data6/state
part /data6/scratch --fstype ext3 --size=100 --grow --onbiosdisk=85
--label=/data6/scratch
part /data7/state --fstype ext3 --size=476160 --onbiosdisk=86
--label=/data7/state
part /data7/scratch --fstype ext3 --size=100 --grow --onbiosdisk=86
--label=/data7/scratch
part /data8/state --fstype ext3 --size=476160 --onbiosdisk=87
--label=/data8/state
part /data8/scratch --fstype ext3 --size=100 --grow --onbiosdisk=87
--label=/data8/scratch
part /data9/state --fstype ext3 --size=476160 --onbiosdisk=88
--label=/data9/state
part /data9/scratch --fstype ext3 --size=100 --grow --onbiosdisk=88
--label=/data9/scratch
part /data10/state --fstype ext3 --size=476160 --onbiosdisk=89
--label=/data10/state
part /data10/scratch --fstype ext3 --size=100 --grow --onbiosdisk=89
--label=/data10/scratch
part /data11/state --fstype ext3 --size=476160 --onbiosdisk=90
--label=/data11/state
part /data11/scratch --fstype ext3 --size=100 --grow --onbiosdisk=90
--label=/data11/scratch
part /data12/state --fstype ext3 --size=476160 --onbiosdisk=91
--label=/data12/state
part /data12/scratch --fstype ext3 --size=100 --grow --onbiosdisk=91
--label=/data12/scratch

I'm assuming that Centos 5 kickstart is more or less the same as whats
in this branch:

http://git.fedorahosted.org/git/anaconda.git?p=anaconda.git;a=tree;h=refs/heads/rhel5-branch;hb=rhel5-branch

My install is dying with here in kickstart.py:

 526         hds = isys.hardDriveDict()
 527         if not hds.has_key(pd.disk) and hds.has_key('mapper/'+pd.disk):
 528             pd.disk = 'mapper/' + pd.disk

Complaining that str can't be concatenated with NoneType. I'm not sure
what is happening because not far above that is:

 462         if pd.onbiosdisk != "":
 463             pd.disk = isys.doGetBiosDisk(pd.onbiosdisk)
 464
 465             if pd.disk == "":
 466                 raise KickstartValueError,
formatErrorMsg(self.lineno, msg="Specified BIOS disk %s cannot be
determined" % pd.onbiosdisk)

One would think that if something went wrong getting the bios disk
that it would have bailed there.

I'm not tied to this method. I just want something that works and that
can handle bios disk order differing from linux disk order. The method
should also be dynamic enough to handle varying number of drives. I
can't find much in the way of doc describing the proper way to do
this. Any suggestions would be greatly appreciated.

Thanks in advance for your time.
Chad




More information about the Kickstart-list mailing list