Bug 56376 - kickstart installations are (sometimes) not longer unattended
Summary: kickstart installations are (sometimes) not longer unattended
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: anaconda   
(Show other bugs)
Version: 7.2
Hardware: i386 Linux
Target Milestone: ---
Assignee: Brent Fox
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2001-11-16 14:49 UTC by Holger Schurig
Modified: 2007-04-18 16:38 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-11-21 09:50:19 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Holger Schurig 2001-11-16 14:49:49 UTC
Description of Problem:
I did about 50 kickstart installations with RH 6.2, they worked complety
I inserted the bootdisk, and RedHat was installing totally unattended. Wow.

Now, with RH 7.2 this seems to be no longer necessary.

Version-Release number of selected component (if applicable):

How Reproducible:
Try the following kickstart file:
lang en_US
langsupport --default en_US en_US
keyboard de-latin1-nodeadkeys
mouse msintellips/2 --device psaux

# The following is really only one line
  --device eth0
  --bootproto static
  --netmask --gateway
  --hostname mnz7.mn-logistik.de

rootpw --iscrypted $1$kTqAzEvP$JOjUIugRoDPKbuDmjDUVa.
firewall --disabled
authconfig --enableshadow --enablemd5
timezone Europe/Berlin
clearpart --linux
part / --fstype ext3 --size=1024
part swap --size=128

and the following SYSLINUX.CFG on the bootnet.img disk:
default ks
prompt 1
timeout 10
display boot.msg
F1 boot.msg
F2 general.msg
F3 expert.msg
F4 param.msg
F5 rescue.msg
label linux
  kernel vmlinuz
  append initrd=initrd.img lang= devfs=nomount ramdisk_size=7168 vga=788
label text
  kernel vmlinuz
  append initrd=initrd.img lang= text devfs=nomount ramdisk_size=7168
label expert
  kernel vmlinuz
  append expert initrd=initrd.img lang= devfs=nomount ramdisk_size=7168
label ks
  kernel vmlinuz
  append ks=floppy initrd=initrd.img lang= devfs=nomount ramdisk_size=7168
label nofb
  kernel vmlinuz
  append initrd=initrd.img lang= devfs=nomount nofb ramdisk_size=7168
label lowres
  kernel vmlinuz
  append initrd=initrd.img lang= lowres devfs=nomount ramdisk_size=7168

Actual Results:
During installation, the system first asks for the language (didn't it find
then for the keyboard (didn't it find that either in the kickstart file?).

Now comes the fun part: when you add the line

nfs --server --dir /u1/redhat72

to the ks.cfg file it actually works. Isn't this weird?

You can make it weirder, really.

In my dhcpd.conf file I have the following:
group {
  use-host-decl-names on;
  filename "/u1/redhat72/mundn/ks.cfg";

  host mnz7 {
    hardware ethernet 00:10:dc:b0:07:7f;
    fixed-address mnz7;

I also changed the 'ks' section in SYSLINUX.CFG to
label ks
  kernel vmlinuz
  append ks=nfs: initrd=initrd.img lang=
devfs=nomount ramdisk_size=7168

and again I get questions for language, keyboard .... but wait, now I got
TONS of questions (NFS Image/HTTP/NFS, DHCP, NFS server and directory).
This is especially weird because before
this questions the messages file on showed the DHCP request
and NFS mount  to
be successfully done ...   and on console 2 I can do a "cd /mnt/source" and
see the files on the
main server.

And it becomes more and more bad. Now, in the graphical install, I have to
select the mouse,
paritions and so on. It looks like the kickstart file has not been
processed at all.

The weirdness is not at it's end, thought. Suppose I don't want to have a
default boot, but want
to have grub stay idle. So I would deselect "Default boot image". However,
this won't work, because
now the NEXT button in the lower right corner is disable, too ...

Expected Results:
It looks like that you did not really test kickstart installation. You have
done better at this before,
but now I am not impressed by the show performance and quality.

If an "nfs" line in the kickstart file is missing, then I would only expect
a installation source (NFS, HTTP, FTP) question, but certainly not a
question on keyboard and language. Similarly, If I put the ks.cfg file on
the NFS and the system is able to do the nfs mount.

Comment 1 Brent Fox 2001-11-20 21:43:25 UTC
Actually, we test kickstart more than any other installation method.  We have an
automated test suite that spits out all kinds of kickstart files for our test
bed machines to install, and they sit there and install around the clock.

I was able to do an NFS kickstart install using the file you used, and I only
changed the IP address and the name of the NFS server.  What driver does your
network card use?  My best guess is that the driver it needs has been moved to
the drvnet.img disk, and the installer is getting confused when it tries to do
an NFS install with no network.

Comment 2 Holger Schurig 2001-11-21 09:50:13 UTC
The driver is eepro100

Ok, sorry, I actually reported more bugs in one message, I shouldn't have done 

Consider the bug on "it looks like the kickstart file has not been processed 
at all" closed. In the SYSCONFIG.CFG file I forgot the trailing '/'. The ks=
entry ends in '.../mundn'. So I guess that kickstart was looking for such a 
file and not finding it (there was only such a directory there). Maybe an 
error msg would have been better. I changed this to '.../mundn/ks.cfg' and it 

However, the other error with ks=floppy and the strange questions still apply.

Comment 3 Brent Fox 2002-01-21 03:05:57 UTC
If you just say 'linux ks=floppy', then anaconda looks for a file called
'ks.cfg' on the root of the floppy.  I don't really understand what the problem
is now that anaconda seems to be processing the kickstart file properly.  Please
reopen this bug report if you are still seeing problems.  Thanks for your report.

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