Bug 6171 - Let's make mkkickstart worth using.
Let's make mkkickstart worth using.
Status: CLOSED DUPLICATE of bug 53073
Product: Red Hat Linux
Classification: Retired
Component: mkkickstart (Show other bugs)
6.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Matt Wilson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-10-20 21:53 EDT by Joshua Jensen
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:
Environment:
Last Closed: 1999-10-20 21:53:46 EDT
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 Joshua Jensen 1999-10-20 21:53:46 EDT
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 12:29:34 EDT

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

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