Bug 10628 - Kickstart install on two drives mirrored with raid 1
Kickstart install on two drives mirrored with raid 1
Product: Red Hat Linux
Classification: Retired
Component: installer (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Michael Fulbright
: 16483 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2000-04-07 03:27 EDT by brian
Modified: 2008-05-01 11:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-04-04 15:15:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
sample ks.cfg file (8.00 KB, text/plain)
2000-04-10 19:59 EDT, brian
no flags 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. (7.84 KB, text/plain)
2000-04-10 20:01 EDT, brian
no flags Details

  None (edit)
Description brian 2000-04-07 03:27:42 EDT
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.
Comment 1 Michael Fulbright 2000-04-10 11:57:59 EDT
Could you attach a sample ks.cfg file that causes this problem?
Comment 2 brian 2000-04-10 19:59:59 EDT
Created attachment 190 [details]
sample ks.cfg file
Comment 3 brian 2000-04-10 20:01:59 EDT
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.
Comment 4 Jay Turner 2000-04-11 12:41:59 EDT
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.
Comment 5 brian 2000-04-13 11:30:59 EDT
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.
Comment 6 Jay Turner 2000-04-18 08:07:59 EDT
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.
Comment 7 brian 2000-04-18 11:50:59 EDT
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?
Comment 8 brian 2000-04-24 18:38:59 EDT
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

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?
Comment 9 Jay Turner 2000-04-27 10:08:59 EDT
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)
Comment 10 Michael Fulbright 2000-06-12 14:48:18 EDT
Test lab - please verify this is fixed in the latest internal release.
Comment 11 Brock Organ 2000-07-13 16:20:04 EDT
--onpart known issues are fixed in winston internal release, but a kickstart
raid issue in the internal release prevents verification of this bug fix ...
Comment 12 Brock Organ 2000-07-13 16:21:41 EDT
... so since the error in winston (internal) kickstart raid exists, verification
using a kickstart file similar to the one above has not been performed ...
Comment 13 Michael Fulbright 2000-08-18 11:53:48 EDT
*** Bug 16483 has been marked as a duplicate of this bug. ***
Comment 14 Brock Organ 2000-08-30 11:46:17 EDT
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__
  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
Comment 15 Michael Fulbright 2001-04-04 15:15:54 EDT
Tested with internal tree today and it was successful.

Note You need to log in before you can comment on or make changes to this bug.