Bug 232400 - kickstart not promting for ip-address when dhcp fail
kickstart not promting for ip-address when dhcp fail
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: anaconda (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: David Cantrell
Depends On:
  Show dependency treegraph
Reported: 2007-03-15 04:22 EDT by Jan-Frode Myklebust
Modified: 2010-10-22 09:43 EDT (History)
3 users (show)

See Also:
Fixed In Version: RHBA-2007-0644
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-11-07 12:20:48 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
anaconda-RHEL-5-kickstartNetworkUp.patch (1.75 KB, patch)
2007-04-05 15:34 EDT, David Cantrell
no flags Details | Diff

  None (edit)
Description Jan-Frode Myklebust 2007-03-15 04:22:02 EDT
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
did before.

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

How reproducible:

Boot the boot.iso with the parameter ks=http://webserver/ks.cfg using the
following ks.cg:

url --url http://webserver/rhel5-i386/
key your-key-here
lang en_US.UTF-8
keyboard no
rootpw --iscrypted $1$6JWjr2dsdsdsjdhjsdi.
firewall --enabled --port=22:tcp
authconfig --enableshadow --enablemd5
selinux --enforcing
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:
Actual results:

Expected results:

Additional info:
Comment 1 Jan-Frode Myklebust 2007-03-24 07:08:22 EDT
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...
Comment 2 David Cantrell 2007-04-05 15:32:48 EDT
This uses the same code that affected bug #210370.  Backporting patch and
attaching to this bug.
Comment 3 David Cantrell 2007-04-05 15:34:17 EDT
Created attachment 151804 [details]
Comment 4 RHEL Product and Program Management 2007-04-05 15:43:13 EDT
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
Comment 9 James Laska 2007-10-12 09:23:24 EDT

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
network settings
Comment 11 errata-xmlrpc 2007-11-07 12:20:48 EST
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.

Comment 12 Thomas Chung 2007-11-19 19:14:55 EST
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.
Thank you. 
Comment 13 James Laska 2007-11-20 07:58:21 EST
thomas.chung: can you please provide the cmdline arguments and the kickstart
file used to recreate your issue?  Many thanks.
Comment 14 Thomas Chung 2007-11-20 13:59:30 EST
Thank you James,
I'll send you the ks.cfg via email attachment.
Comment 15 Robert Hancock 2007-12-18 14:08:45 EST
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
wrong. Argh..
Comment 16 Thomas Chung 2007-12-18 14:25:29 EST
FYI, we're using following as a work-around:

In a custom bootable kickstart CD, we added following stanza in isolinux.cfg
label <org> 
    kernel vmlinuz
    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.
Comment 17 Robert Hancock 2007-12-18 15:37:01 EST
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.

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