Description of problem: We're running kickstarts of RHEL at a customer that
doesn't have DHCP on his network, so we have a kickstart configuration file that
doesn't include a ^network line. Earlier that lead to kickstart trying to get
IP-address from DHCP, and prompt for the user to specify it when DHCP fails.
With RHEL5 this doesn't happen. It prompts for an IP-address before it fetches
the ks.cfg, but after it gets it it again does DHCP doesn't ask again like it
Version-Release number of selected component (if applicable):
Boot the boot.iso with the parameter ks=http://webserver/ks.cfg using the
url --url http://webserver/rhel5-i386/
rootpw --iscrypted $1$6JWjr2dsdsdsjdhjsdi.
firewall --enabled --port=22:tcp
authconfig --enableshadow --enablemd5
timezone --utc Europe/Oslo
bootloader --location=mbr --driveorder=sda --append="rhgb quiet"
clearpart --all --initlabel
part /boot --fstype ext3 --size=128
part pv.0 --size=0 --grow
volgroup rootvg pv.0
logvol / --fstype ext3 --name=rootlv --vgname=rootvg --size=5120
logvol swap --fstype swap --name=swaplv --vgname=rootvg --size=2048
logvol /var --fstype ext3 --name=varlv --vgname=rootvg --size=3072
Steps to Reproduce:
BTW: I've changed my kickstart-file to include the full ^network line, so this
isn't that much of a problem to me any more..
But, since we're not using DHCP on our network, it would be great if it was
possible to disable also the first DHCP query when booting from boot.iso. It's
slow and a bit annoying to have to wait for it...
This uses the same code that affected bug #210370. Backporting patch and
attaching to this bug.
Created attachment 151804 [details]
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release. Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products. This request is not yet committed for inclusion in an Update
Tested the following with a kickstart that contained a network line, and one
1. Booted anaconda with "ip=dhcp noipv6 ks=..."
2. stage#1 completes and transitions to stage#2 without prompting for additional
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.
Is there an updated boot.iso with patches?
I just tried kickstart install with nfs option on RHEL 5.1 but it failed since
it never asked for static ip address as described in this bug.
FYI, it worked perfectly fine on RHEL 5.0.
thomas.chung: can you please provide the cmdline arguments and the kickstart
file used to recreate your issue? Many thanks.
Thank you James,
I'll send you the ks.cfg via email attachment.
I am also having this issue with the Update 1 installer. It seems like it
essentially makes it impossible to do a network install using a CD-based
kickstart with a static IP address without hard-coding the IP in the kickstart
file (which is useless - why would I want to configure all machines with the
same IP..) If I delete all network lines out of the kickstart file, 5 worked as
expected and prompted you for the IP address before getting the web address to
install from, but now it just assumes you want to use DHCP on eth0, which is
FYI, we're using following as a work-around:
In a custom bootable kickstart CD, we added following stanza in isolinux.cfg
append initrd=initrd.img ks=cdrom netmask=<netmask> dns=<dns>
Then we type following in the boot.
boot: <org> ip=<ip> gatway=<gatway>
It works beautifully for our static-ip envoriment.
In fact, it doesn't work with a non-DHCP network install using an HTTP-provided
kickstart file, either. First of all, when trying to load the kickstart file, it
tries to obtain a DHCP address after I just told it to configure the IP address
manually. Secondly, when trying to actually get the files off the network, it
fails. I can't tell why, but I suspect the default gateway I specified is not
being applied properly. (Might be related to it still attempting DHCP.)
What this essentially means is that network installs using a static IP seem to
be entirely broken.