Bug 6171

Summary: Let's make mkkickstart worth using.
Product: [Retired] Red Hat Linux Reporter: Joshua Jensen <joshua>
Component: mkkickstartAssignee: Matt Wilson <msw>
Status: CLOSED DUPLICATE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6.1CC: pavel.janik
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 1999-10-21 01:53:46 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Joshua Jensen 1999-10-21 01:53:46 UTC
mkkickstart gets it wrong everytime:

1) Timezone that is specified isn't in the correct format

2) The mouse specification is wrong.  The installer wants
kickstart to say something like: genericps/2... the
mkkickstart script lazily puts out ps/2 from the MOUSETYPE=
line in /etc/sysconfig/mouse.  This doesn't work.

3) iscrypted not only doesn't work with encrypted passwords
(just like in 6.0), it crashes the entire kickstart proccess
with Python debuging errors.  Non-encrypted passwords work.

4) lilo isn't written from the system.  All you get from the
output of mkkickstart is a commented "append something"
line.  Can't we make it so it actually senses from
/etc/lilo.conf where lilo is installed?  All that has to be
done is read the boot= line in lilo.conf, and then give
something like:  lilo --location mbr

5)  partition information is at least wrong, usually
missing.  In 6.0, mkkickstart gave us partitions of size 1.
Now, we don't even get that; there isn't any information
supplied at all.  I think this is because fdisk -l with no
device specified doesn't work (see bug 6148 that I entered
earlier).  Once fdisk is fixed, can we make mkkickstart give
real numbers too?

6) All commands in the post section have a ^M append on to
them.  I am using vi -b to edit the ks.cfg file, but the ^M
is still there.  Python is confused about the dos -vs- unix
line endings.  This is a problem when I do:
echo > /tmp/test
and I get /tmp/test? or /tmp/test^M
One workaround to this is putting a semicolon at the end of
every line in the post section.  :-(

Comment 1 Matt Wilson 2001-09-10 16:29:34 UTC

*** This bug has been marked as a duplicate of 53073 ***