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.
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.
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?
This issue also occurs with kickstart on a guest in VMware Server, which loads the e1000 as it's virtual NIC.
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.
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
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.
Any progress on whether this is still an issue in F9?