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.
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] 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
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
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:
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__
File "/usr/lib/anaconda/kickstart.py", line 440, in readKickstart
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
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
Tested with internal tree today and it was successful.