when using redhat 6.2's ability to boot from a completely mirrored system I've run into a problem with kickstart as well as the hands on installer. When I allow diskdruid or kickstart to create the "fd" partitions for use within a md device it fails to make sure that the /boot partition that I've created out of two 32M "fd" partitions are the firt partitions on the each of the drives I'm using. This is not true when creating a /boot partion without the use of raid. IN that case the system works jus fine. So my work around has been to, on the hands on installation, use fdisk to hard set things my way. But kickstart doesn't appear to allow me to do that. Ideas?
Could you attach a sample ks.cfg file that causes this problem?
Created attachment 190 [details] sample ks.cfg file
Created attachment 191 [details] Second pass at ks.cfg file. This one was also a failure and I used a different raid.<ID> scheme to keep things in order if a sort was issued.
Please submit details of the error that you are getting when using kickstart. The machine really does not care where /boot is located, as long as it is below the 1024 cylinder limit, so I am not quite sure the problem you are seeing.
It does care though when the drive is large enough that the 1024 limits are a real concern. Also a side note, for performance I put the second ide drive on the second ide controller. Linux tends not to use LBA for drives on the second controller unless you want to pass geometry info into lilo at boot time. As such anything but the first partition is hard to keep under the 1024 limit on the second ide drive whichis attached to the second ide controller. This is a real problem for me and I assume anyone else doing similar things, i.e. using two ide drives one per controller for a mirrored os. It also seems sloppy to end up with a /boot on hda9 and hdc9. Doesn't make for a system that is easy to repair since you no longer can expect the first partition to contain the kernel images. The only "HACK" that I've been able to find is to not raid /boot. But this now makes my system just as vunerable as if I didn't raid the rest of the system. Kind of a waste. I'm having a hard time reading from your reply's if you believe this is a problem and as such it will be fixed or if I'm being told it doesn't matter and to drop the issue. Please be more up front if this is what your thinking.
Kickstart allows the use of the "--onpart" argument in combination with the "part" statements to specify where a particular partition is supposed to land on the drive. The only drawback here is that the partition has to exist already before kickstart will be able to assign a partition to it. So, I would recommend specifying which partition (hda1 and hdb1) you want the /boot partition to land on and then go from there.
I will look into --onpart. I had seen this option before and was a little put off in that like you said it requires the partition to already be there. Well for large scale systems such as university labs and or beowulf clusters to name only a couple possibilities this doesn't scale well. The whole idea of kickstart that caught my interest was that we did not have to hand do each machine. Well having to do the partitions is almost that bad. Especially for our beowulf cluster that does not have a monitor on each system. Imagine having to move a monitor to over 180 machines just to partition them. Not a fun day. Not efficient either. Is this going to be resolved for 6.2 or will it get pushed off till a future release?
I've now tried to use the --onpart trick as follows: part raid.a1 --onpart hda1 part raid.a2 --onpart hdc1 part swap --onpart hda5 part swap --onpart hdc5 part raid.b1 --onpart hda6 part raid.b2 --onpart hdc6 part raid.c1 --onpart hda7 part raid.c2 --onpart hdc7 part raid.d1 --onpart hda8 part raid.d2 --onpart hdc8 part raid.e1 --onpart hda9 part raid.e2 --onpart hdc9 raid /boot --level 1 --device md0 raid.a1 raid.a2 raid / --level 1 --device md1 raid.b1 raid.b2 raid /uufs/icebox/host --level 1 --device md2 raid.c1 raid.c2 raid /var --level 1 --device md3 raid.d1 raid.d2 raid /uufs/icebox/host/pvfs/meta --level 1 --device md4 raid.e1 raid.e2 All partitions hd[ac][156789] exist with proper partition tags but I get an error after running the ks.cfg file that raid.a1 does not exist and it then stops. So I seem to have to come back to the notion that RedHat or someone just doesn't care that this is a showstopping bug for those that wanted to use kickstart in a large scale production system that wants to use a completely mirrored system. What will it take to get this fixed?
Well, it has come to out attention that there is actually a bug in the "--onpart" code which might be causing the bug you are seeing. We are working on the "--onpart" bug and then we will attack this bug (if it still exists after the fix)
Test lab - please verify this is fixed in the latest internal release.
--onpart known issues are fixed in winston internal release, but a kickstart raid issue in the internal release prevents verification of this bug fix ...
... so since the error in winston (internal) kickstart raid exists, verification using a kickstart file similar to the one above has not been performed ...
*** Bug 16483 has been marked as a duplicate of this bug. ***
This is not resolved in Winston: The following partition section of a sample ks file shows the error: zerombr yes part / --onpart hda1 part swap --onpart hda17 #part raid.5 --onpart hda5 <- FAILS #part raid.6 --onpart hda6 <- FAILS #part raid.7 --onpart hda7 <- FAILS #part raid.8 --onpart hda8 <- FAILS part raid.5 --size 100 <- WORKS part raid.6 --size 100 <- WORKS part raid.7 --size 100 <- WORKS part raid.8 --size 100 <- WORKS Here is the traceback: Running anaconda - may take some time to load... Traceback (innermost last): File "/usr/bin/anaconda", line 329, in ? instClass = Kickstart(kickstart, serial) File "/usr/lib/anaconda/kickstart.py", line 602, in Kickstart ksClass = KickstartBase(file, serial) File "/usr/lib/anaconda/kickstart.py", line 563, in __init__ self.readKickstart(file) File "/usr/lib/anaconda/kickstart.py", line 440, in readKickstart handlers[args[0]](args[1:]) File "/usr/lib/anaconda/kickstart.py", line 485, in defineRaid self.addRaidEntry(mntPoint, raidDev, level, extra) File "/usr/lib/anaconda/installclass.py", line 63, in addRaidEntry raise ValueError, "unknown raid device %s" % (device,) ValueError: unknown raid device raid.5 install exited abnormally sending termination signals... Here was the initial partition table of the disk (note all the type fd partitions are 100Mb in size): % fdisk -l /dev/hda Disk /dev/hda: 255 heads, 63 sectors, 787 cylinders Units = cylinders of 16065 * 512 bytes Device Boot Start End Blocks Id System /dev/hda1 * 1 128 1028128+ 83 Linux /dev/hda2 129 787 5293417+ 5 Extended /dev/hda5 129 141 104391 fd Linux raid autodetect /dev/hda6 142 154 104391 fd Linux raid autodetect /dev/hda7 155 167 104391 fd Linux raid autodetect /dev/hda8 168 180 104391 fd Linux raid autodetect /dev/hda9 181 193 104391 fd Linux raid autodetect /dev/hda10 194 206 104391 fd Linux raid autodetect /dev/hda11 207 219 104391 fd Linux raid autodetect /dev/hda12 220 232 104391 fd Linux raid autodetect /dev/hda13 233 245 104391 fd Linux raid autodetect /dev/hda14 246 258 104391 fd Linux raid autodetect /dev/hda15 259 271 104391 fd Linux raid autodetect /dev/hda16 272 284 104391 fd Linux raid autodetect /dev/hda17 285 297 104391 82 Linux swap
Tested with internal tree today and it was successful.