Bug 56499 - anaconda fails to pick up address on first pass during PXE/bootp install
anaconda fails to pick up address on first pass during PXE/bootp install
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: anaconda (Show other bugs)
7.2
i386 Linux
medium Severity low
: ---
: ---
Assigned To: Matt Wilson
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-11-19 21:14 EST by K. Spoon
Modified: 2007-04-18 12:38 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-01-15 16:48:41 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch to anaconda to make multiple DHCP reqs for network kickstart (953 bytes, patch)
2001-11-19 21:16 EST, K. Spoon
no flags Details | Diff

  None (edit)
Description K. Spoon 2001-11-19 21:14:02 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014

Description of problem:
Using PXELINUX to grab the kernel and initrd via bootp from a kickstart
server, anaconda is unable to pick up an IP address from the DHCP server
and reverts back to manual install.  Once in manual install mode, you may
request a Dynamic IP a second time, and anaconda will successfully get that
request.

Looking at the DHCP server logs it is clear that the server is responding
with a OFFER to both of pump's DISCOVERs, but for some reason the pump
portion of anaconda never acknowledges the response.

Note that a minor change to loader.c to make it try several times to get a
DHCP address seems to solve the problem (address is picked up on the second
attempt).

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


How reproducible:
Always

Steps to Reproduce:
1. setup dhcpd to provide bootp booting services
2. install PXELINUX in tftp dir on server
3. set NIC in server to boot from network
4. select install label, and go.  Wait for DHCP request to grab the ks.cfg.
	

Actual Results:  The DHCP request fails, which keeps loader from picking up
the ks.cfg from the kickstart server (via NFS) fails, and the installer
drops back into interactive mode.

Expected Results:  DHCP request worked and installer shouldn't bug me until
the post-install.  :-)

Additional info:

PXELINUX version: 1.63
isc-dhcpd version: tried both dhcp-2.0pl5-8 and dhcp-3.0
DHCP/kickstart server running RHL 6.2
All servers using Intel Pro 100/S NICs (e100 driver on the dhcp server,
eepro100 on 7.2 from 2.4.7-10)

No other systems (wide variety of OS's and archs) have problems picking up
a DHCP address... including floppy based kickstarts for RHL 6.2 to 7.2

A patch that makes anaconda try sending multiple DHCP requests (4) should
be attached and seems to solve the problem... IP address is acknowledged on
the second attempt.
Comment 1 K. Spoon 2001-11-19 21:16:06 EST
Created attachment 37986 [details]
patch to anaconda to make multiple DHCP reqs for network kickstart
Comment 2 Brent Fox 2001-11-20 13:40:51 EST
This is strange because we do kickstart PXE boot installs all the time.  Any
ideas here Matt?
Comment 3 K. Spoon 2001-11-20 16:22:49 EST
The big thing I'm concerned about is getting anaconda to give DHCP a couple of
tries before giving up on a DHCP server.  Missing one round of DHCPOFFERs isn't
worth dropping out of a kickstart for, IMO.

Regarding the actual cause, I think the big problem is that we're using PXELINUX
(an offshoot of syslinux) that is being served up from bootp/dhcpd rather than a
true PXE server.  It seems as if pump is getting confused by something PXELINUX
is doing and that after pumpDhcpRun() is run the first time, the problem is
reset.  I haven't been able to replicate it under any other circumstances.
Comment 4 Jeremy Katz 2001-11-28 20:08:14 EST
Not that I'm necessarily against the idea of adding a retry, but we use pxelinux
here as well.  If you take a look at the dhcp packets on the network, is there
anything "strange" about them?
Comment 5 Brent Fox 2001-12-08 12:30:21 EST
Any more info here?
Comment 6 K. Spoon 2001-12-10 14:13:30 EST
Yeah, but given the security updates of the past week and some other stuff that
has to get done before holidays I haven't had a chance to gather detailed info.

I do recall that the "breq" field wasn't matching up with "bresp" on the first
try... couldn't tell if they matched on the second try since the info scrolls
off the screen.  Example: installer thinks its listening for "0xb7b34f54" and
dhcp server sees "0xb748514d" and responds accordingly (card's MAC is
00:02:b3:48:51:4d).  It didn't look like anything strange or unexpected was
happening on the network's side of things.

Hopefully, before the end of the week I will have tcpdump logs and have figured
out some way to capture all the info pump is spitting out.

Please let me know if there's some debugging code I can turn on that might help.
Comment 7 K. Spoon 2001-12-18 04:03:35 EST
It seems the problem was in the version of pxelinux being used.  Using version
1.65 (recent release) as well as 1.52 from the RH 7.2 CDROMs, everything is cool 
(response from DHCP server picked up right away), but trying a kickstart using
1.63 still seems to trip it up.

It'd still be nice to have anaconda not give up so easily.  :-)
Comment 8 Matt Wilson 2002-02-11 19:18:12 EST
Multiple passess will take a very long time to time out.  Normally everything
works fine, but PXELINUX was known to have some bugs that caused things like this.

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