Bug 258881

Summary:	Anaconda netboot fails to DHCP
Product:	[Fedora] Fedora	Reporter:	Jonathan S. Shapiro <shap>
Component:	anaconda	Assignee:	Anaconda Maintenance Team <anaconda-maint-list>
Status:	CLOSED INSUFFICIENT_DATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	medium
Version:	9	CC:	alindebe, cwbshaw, triage
Target Milestone:	---
Target Release:	---
Hardware:	i686
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2008-08-04 14:19:38 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Jonathan S. Shapiro 2007-08-28 02:15:52 UTC

This may be a kernel bug, but it is blocking F7 installs by a major hosting
provider, so documenting a workaround is high priority.

Scenario:

Machine is booted using PXE (therefore DHCP) and directed to a kickstart file
that in turn provisions the nic (eth0 or eth1) using bootproto dhcp. Attempts to
fetch stage2 image fail. If you watch the alt-f3 screen at just the right time,
you can see that the machine is correctly obtaining a DHCP lease on that
interface, and then four lines later attempts another DHCPREQUEST transaction.
It is the second attempt that is failing.

As I say, this may be a kernel bug. On both machines where it has been observed,
the NIC driver is e1000. Installing a machine from th F7 release DVD (i.e.
without updates) and configuring for DHCP has the curious property that if you
manually down and re-up the interface after install the re-up will fail. This
failure does not occur with the current kernel version. Please note, however,
that I saw this behavior *once*, and it may have been an anomaly. If it is
important, please let me know soon and I can re-test, since I have a machine
that I can whack with impunity for another day or so.

Present workaround:

At present, I have managed to work around the problem by configuring the NICS in
the kickstart script using an initial static IP, and then whacking the NIC
config files on the target in a postinstall scrupt. I have provided this
workaround to the hosting provider and I suspect they will adopt it, but note
that this only works if DHCP leases are static or the deployer is in control of
a CGI script that can consult the DHCP server to find out what address was issued.

Comment 1 Jonathan S. Shapiro 2007-08-28 03:45:12 UTC

Still not sure if this is significant, but both of the machines where we have
seen this are using e1000 NICs, and the problem seems to be machine dependent.
I've pointed the hosting provider at this bug report; maybe they'll add info.

If we respin the release with revisor, and then netboot the installer from the
respin, will that cause the install-time kernel to be updated as well? That
would be desirable for other reasons as well.

Comment 2 Chris Bradshaw 2007-10-15 15:23:40 UTC

Just to report that I am also seeing the same problems with some Dell PowerEdge
750's which have E1000 NIC's. 

Would it be possible for me to rebuild the netboot kernel and/or initrd with
more recent versions of the e1000 module?

If so how?

Comment 3 Aaron McSorley 2007-10-25 23:02:09 UTC

This issue also occurs with kickstart on a guest in VMware Server, which 
loads the e1000 as it's virtual NIC.

Comment 4 Chris Bradshaw 2007-10-26 09:01:11 UTC

I found this issue being discussed at the Fedora Community Portal....here is one
of the thread URLs:

http://fcp.surfsite.org/modules/newbb/viewtopic.php?topic_id=41083&forum=10&post_id=189206#forumpost189206

Anyway, one of the posters to the thread rebuild an i386 and x86_64 initrd image
with the latest e1000 drivers and made them available at:

http://www.shells.nl/junk/F7e1000/

I have tried the i386 version and it seems to work....I haven't got an x86_64
machine with an e1000, but other reports on the thread suggest both work.

Hope this helps.

Comment 5 Bug Zapper 2008-05-14 14:07:36 UTC

This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 6 Jonathan S. Shapiro 2008-05-14 14:41:14 UTC

Updating this to F9 so that I can re-test. If it's resolved, I'll close. Note: I
don't actually know if this bug remains in F9.

Comment 7 Andy Lindeberg 2008-06-02 20:07:09 UTC

Any progress on whether this is still an issue in F9?