Bug 6171 - Let's make mkkickstart worth using.
Summary: Let's make mkkickstart worth using.
Keywords:
Status: CLOSED DUPLICATE of bug 53073
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: mkkickstart
Version: 6.1
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Matt Wilson
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1999-10-21 01:53 UTC by Joshua Jensen
Modified: 2008-05-01 15:37 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 1999-10-21 01:53:46 UTC
Embargoed:


Attachments (Terms of Use)

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 ***


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