Bug 55469 - ksconfig --onprimary option causes traceback in kickstart installation
ksconfig --onprimary option causes traceback in kickstart installation
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: ksconfig (Show other bugs)
7.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Brent Fox
:
: 55613 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-10-31 14:29 EST by Jeff Lane
Modified: 2008-05-01 11:38 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-01-26 23:59:34 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jeff Lane 2001-10-31 14:29:42 EST
Description of Problem: I created a 7.2 custom-everything install kickstart
script that looks like this:

#Generated by Kickstart Configurator
lang en_US
langsupport en_US
keyboard us
mouse generic3ps/2
skipx
timezone --utc America/New_York
rootpw *********
bootloader --location=mbr
install
nfs --server stoker --dir /mnt/dist/7.2/i386
clearpart --all
part /boot --fstype ext3 --size 100 --onprimary 1             
part / --fstype ext3 --size 1000 --grow
part  swap --size 512
network --bootproto dhcp
auth  --useshadow  --enablemd5
firewall --disabled
%packages
@Everything
%post

I removed the comments that ksconfig inserted, and I have some post install
commands as well that I did not include here.

Now, when I do the kickstart install, I get a traceback error that says:

Traceback (innermost last):
file "/usr/bin/anaconda", line 589, in ?
	instClass.setInstallData(id)
file "/usr/lib/anaconda/kickstart.py", line  835, in setInstallData
	self.readKickstart(id, self.file)
file "/usr/lib/anaconda/kickstart.py", line  557, in readKickstart
	handlers[args[0]](id, args[1:])
file "/usr/lib/anaconda/kickstart.py", line  683, in definePartition
	(args, extra) = isys.getopt(args, '', [ 'size=', 'maxsize=',
file "/usr/lib/anaconda/isys.py", line  301, in getopt
	return apply(_isys.getopt, args)
TypeError: bad arguement --onprimary: unknown option

This has happened on three different machines when using the --onprimary
option in formatting.  I havent tried this with a manual install, so I dont
know for sure if it is an anaconda thing, or is specific to kickstart.

Version-Release number of selected component (if applicable):
would be a 7.2 install, ks.cfg was created with 
ksconfig-1.9.8-4

How Reproducible:
should be easily reproducible.

Steps to Reproduce:
1. create ks.cfg with ksconfig and select onprimary when setting up
partitions.
2.  run kickstart install on a machine using that ks.cfg and installing 7.2


Actual Results:

traceback as shown above

Expected Results:
force the selected partition to be on a primary partition and not an
extended partition.

Additional Information:
I have the machines that do this here in Meridian, I can show you if you
would like...
Comment 1 Jeff Lane 2001-10-31 14:35:15 EST
also, when I remove the --onprimary option from ks.cfg, the install proceeds
properly, except for a mouse probing problem, but that is a different story.

Comment 2 Brent Fox 2001-10-31 16:07:58 EST
This is really an anaconda bug instead of a ksconfig bug.  ksconfig is writing
out a valid file according to the kickstart documentation.  This is a dupe of
bug #55373

*** This bug has been marked as a duplicate of 55373 ***
Comment 3 Brent Fox 2001-11-03 12:01:58 EST
*** Bug 55613 has been marked as a duplicate of this bug. ***
Comment 4 Brent Fox 2001-11-03 20:43:09 EST
*sigh*.  Ok, I can confirm that --onpart has been removed from kickstart.  With
7.2, we switched the disk partitioning backend from libfdisk to parted.  Parted
lacks the ability to specify specific partitions the way that libfdisk did, but
the benefits that parted provides us outweighed the negatives.  

The problem is that the removal was not well communicated, therefore the
kickstart docs still mention --onprimary and ksconfig still lets the user call
that flag.  The docs have been updated to describe the new behavior, and I will
have to remove the --onprimary code from ksconfig.

I'm not happy with this, but I don't see anything else I can do at the moment.
Comment 5 Brent Fox 2001-11-03 23:42:07 EST
Correction....--onprimary has been removed...not --onpart.

Comment 6 Need Real Name 2001-11-05 09:23:19 EST
I am not happy with this either.  :-(

The --onprimary tag is the only way to slice up the disk with ks to put the 
partitions exactly the way you want them.  I am not sure how --asprimary 
decides where to put partitions, but it doesn't do it based on the order listed 
in the kickstart file.  I like to have swap at the beginning of the disk, but 
asprimary always puts it as the last partition.

How does RH now recommend to create partitions for something like:
1 /    2000M
2 swap 1000M
3 /var 2000M
4 /usr 2000M

Is it possible to format the disk during %pre and then use --onpart to put the 
partitions in the right place?  I do not really care how it is done, but need 
the ability to do everything from kickstart.

Comment 7 jeff 2001-11-05 12:49:34 EST
I could live with --onprimary if I could see a concrete example of
manually partitioning the disks in a %pre section.

However, The example would need to demonstrate how to:
a) determine which disk is the boot disk /dev/hda or /dev/sda.
   I would want an example that could be used on either an IDE
   or a SCSI based system without making changes to the ks file.
b) How do I clear all existing partitions from the drive.
   (I guess you could delete partitions 1, 2, 3 and 4 during the fdisk)
c) How would you detect an unitialized partition and then initialize it
   in case its a shiny new (or currupted) disk.

I tried doing this myself but my fdisk /dev/hda << EOF doesn't seem to
work because it doesn't seem to grok all the end-of-lines as "Enter"
key inputs.
Comment 8 Brent Fox 2001-11-06 17:17:56 EST
Yes, it is possible to fdisk the drive during %pre and then use --onpart to
specify the correct partition(s), although it is not pretty.  I'll try to put
together an example %pre that demonstrates this.
Comment 9 Brent Fox 2001-11-06 17:25:04 EST
For example, to create a 400MB swap as /dev/hda1 and a 3000MB / as /dev/hda2,
you could do something like this:

%pre
mknod /tmp/hda
fdisk /tmp/hda << EOF
n
p
1
+400M
t
1
82
n
p
2
+3000M
t
2
83
p
w
EOF



Each line is essentially a command to fdisk.  If you think of the key sequence
necessary to set up your partitions in fdisk, and then put each command on a
separate line, this should do the trick.

Then, you would use --onpart to specify /dev/hda1 for your swap and /dev/hda2
for your root.  This is terribly inelegant, but it should work.
Comment 10 travis__scott 2001-11-17 13:32:06 EST
the script above does not seem to work for me.  I get "unable to find 
partition /hda/dev2 to use for /".

here is the script I used.

mknod /tmp/hda
fdisk /tmp/hda << EOF
n
p
2
+2000M
t
2
83
n
p
3
+100M
t
3
82
p
w
EOF
Comment 11 Brent Fox 2002-01-26 23:59:28 EST
Hmm...I don't know what the problem is.  It seems like your script should work
to me...
Comment 12 Brent Fox 2002-02-28 17:03:11 EST
At any rate, I have built a new version of ksconfig in Rawhide that doesn't
allow the creation of --onprimary partitions since that option is no longer
available.

It is ksconfig-1.9.9-1.noarch.rpm

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