Bug 232400 - kickstart not promting for ip-address when dhcp fail
Summary: kickstart not promting for ip-address when dhcp fail
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: anaconda
Version: 5.0
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
: ---
Assignee: David Cantrell
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-03-15 08:22 UTC by Jan-Frode Myklebust
Modified: 2018-10-19 23:33 UTC (History)
3 users (show)

Fixed In Version: RHBA-2007-0644
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-11-07 17:20:48 UTC
Target Upstream Version:
Embargoed:


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


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2007:0644 0 normal SHIPPED_LIVE anaconda bug fix and enhancement update 2007-10-30 22:56:59 UTC

Description Jan-Frode Myklebust 2007-03-15 08:22:02 UTC
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:

install
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
%packages
@system-tools


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Jan-Frode Myklebust 2007-03-24 11:08:22 UTC
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 19:32:48 UTC
This uses the same code that affected bug #210370.  Backporting patch and
attaching to this bug.

Comment 3 David Cantrell 2007-04-05 19:34:17 UTC
Created attachment 151804 [details]
anaconda-RHEL-5-kickstartNetworkUp.patch

Comment 4 RHEL Program Management 2007-04-05 19:43:13 UTC
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
release.

Comment 9 James Laska 2007-10-12 13:23:24 UTC
VERIFIED.

Tested the following with a kickstart that contained a network line, and one
without.

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 17:20:48 UTC
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.

http://rhn.redhat.com/errata/RHBA-2007-0644.html


Comment 12 Thomas Chung 2007-11-20 00:14:55 UTC
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 12:58:21 UTC
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 18:59:30 UTC
Thank you James,
I'll send you the ks.cfg via email attachment.


Comment 15 Robert Hancock 2007-12-18 19:08:45 UTC
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 19:25:29 UTC
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 20:37:01 UTC
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.