Description of problem: When trying to install rawhide (under VMware Workstation), using the boot.iso to initiate a network-based install, the network interface is not initialized probably (network appears to be down). On the Alt+F3 message screen, I get: WARNING: no network link determined on eth0 Continuing with IPv4 DHCP, I get the following from the log: DHCPDISCOVER send_packet: Network is down Continuing anyway, with manual IPv4 addy, it fails after entering the details about my FTP source server. ERROR: cannot determine address family of ftpserver.local.net I've tried a different virtual network adapter (emulated e1000) and a physical machine with the same results (have tried physical machine only with DHCP) all with exactly the same results. Both virtual machine and and physical have been i386 machines. Steps to Reproduce: 1. Boot from boot.iso 2. Attempt to get DHCP address or connect to ftp server 3. Actual results: Fails miserably Expected results: Just Works (tm)
Just tried the x86_64 version of boot.iso with a 64-bit VM with the exact asme results.
I've seen it on x86_64/e1000 with both boot.iso and pxelinux. That was the 2006-12-26 tree.
*** Bug 220748 has been marked as a duplicate of this bug. ***
Asking kernel... DaveJ, I'm banging my head against this problem and the only thing that has changed in rawhide with regard to what was working for dhcp in the installer is the kernel. I cannot configure an interface manually either. So my guess is that the driver I'm using is busted -or- there's something new that I need to be doing in userspace to put the interface in the right state. The reporter and I are both using e1000. dhclient gets SIOCSIFFLAGS: Resource temporarily unavailable messages and fails.
As stated, I've tried with VMware's default NIC type too (I merely failed to mention that that NIC is using the pcnet32 driver). So I have three different drivers on two different systems behaving the same. e100 e1000 pcnet32 They all do the same for me.
OK, I've put together a custom vmlinuz+initrd.img using the last 2.6.18 kernel RPM I can find for Fedora. Things work fine with that. So since this covers a wide range of network adapters and it works fine with the old kernel, I'm reassigning this to the kernel.
David, what is the exact version of "the last 2.6.18 kernel RPM [you] can find for Fedora"? That may help to point at a change.
(In reply to comment #7) > David, what is the exact version of "the last 2.6.18 kernel RPM [you] can find > for Fedora"? That may help to point at a change. And by Fedora, I meant a RHEL-5 nightly. Specifically, the one from RHEL5-Server-20070105.nightly. So many trees.
This appears to still be a problem on boot.iso from today (Jan 08, 2007). Do you need more info or? Do you have an idea if this is a problem everywhere or only under special circumstances? Should it be marked as a blocker???
I'm also encountering this problem on a physical computer here (hp compaq dc7700) The used network driver is e1000. Running with kernel 2.6.19-1.2906.fc7
Erik, if you are having this problem on a physical machine, Can you set the debug module option on the e1000 driver to 16. That may give us some idea of whats happening. I think there is a way to specify module options to pass to various modeules loaded by anaconda (perhas via a driver disk?)
If you could tell me how to set this module option from within anaconda's stage 1 or the kernel bootloader I'm sure willing to test :)
Just tried with the current boot.iso (i386 and x86_64) and networking works again as expected. Tried with e1000 and pcnet32 both work now. Thanks a lot, good work guys.
ok, closing since this seems to have been a transient anomaly. Please open a new bug if this recurrs. Thanks