Description of problem: No network running on a frest instaall Version-Release number of selected component (if applicable): How reproducible: Simply install Fedora 9 x86_64 Steps to Reproduce: 1. 2. 3. Actual results: No network Expected results: Network should be available Additional info:
Please attach any ifcfg files from /etc/sysconfig/network-scripts/ that are on your system, like ifcfg-eth0. Also, if you could grab and install this NM update and report whether that helps: http://koji.fedoraproject.org/koji/taskinfo?taskID=608593 Did you install from the LiveCD, and how did you configure the networking in the installer?
Created attachment 305412 [details] ifcfg-eth0 file Here is the requested file.
I have installed from the full DVD release. I have left the configuration to dynamically use DHCP. For some reasons, the installation originally did not recognize the network. I have updated NetworkManager to find out that SELinux policies denied NetworkManager for some odd reasons. I will submit these bugs on security team which are related. Currently, my Fedora 9 installation has no online access.
Could you attach the audit.log?
Created attachment 305527 [details] audit file For some reasons, dhcp_t got denied.
In my case, problem was solved by manual editing of ifcfg-eth0. I changed NM_CONTROLLED=no to NM_CONTROLLED=yes and after reboot it works fine (solution posted to FedoraForum by Marley Junior). My opinion is that problem is created in moment when you specify fixed ip in installation process, but I am unable to test it currently. Mine is also installed from install DVD.
Tried the solution from #6.NM is connected but no Internet access.
(In reply to comment #6) > In my case, problem was solved by manual editing of ifcfg-eth0. I changed > NM_CONTROLLED=no to NM_CONTROLLED=yes and after reboot it works fine (solution > posted to FedoraForum by Marley Junior). > My opinion is that problem is created in moment when you specify fixed ip in > installation process, but I am unable to test it currently. > Mine is also installed from install DVD. Testing the i386 version LiveUSB of Fedora 9, NetworkManager runs smoothly. This result confirms the bug affects x86_64 platform.
Created attachment 305746 [details] ifcfg-etho from installed i386 fedora 9 I included the attachment from i386 installation. NetworkManager runs without the issue. I have repeated the same test with the x86_64 were NetworkManager will not work even using suggested workaround. For these reason, I will raise the issue to high.
So this should be two bugs, one x64 related and one setup related. Mine is very easily to reproduce:fill static IP in setup. It may depend on secondary wireless connection. I tried fresh setup, ignored setup dialog about network (leaving dhcp there) and then I set everything in nm applet. It works fine now.
(In reply to comment #10) > So this should be two bugs, one x64 related and one setup related. Big update, I found out about the cause of bug. My PC motherboard, a Gigabyte GA-K8SNC-939 got the enabled support to 4GB because there is already 4 x 1 OCZ Platinum GB DDR-RAM installed. What is surprising is once I disabled that support, NetworkManager is able to connect without problem using the x86_64 Fedora 9 liveUSB. I never had that issue on the x86 version with the 4GB support enabled. In this case, it looks like the bug is critical than I thought especially for people having more than 4GB in their workstations. Currently, I run x86_64 with 4GB support disabled. I have reproduced the same thing on Fedora 8 and noticed the same issue in the same architecture. That report should be investigated as soon as possible because it appears to be hardware related. If the bug is not critical, please let users know.
I wonder if the issues is more kernel related than NetworkManager.
Probably more kernel-related; NM shouldn't care about the amount of memory, but the drivers might care. There have been bugs historically with broadcom wifi cards having issues with > 2G or 3G, I forget which.
I have the same GA-K8NSC-939 motherboard, along with a PCI nic. Network Manager marked both as "unmanaged" AND the network script in /etc/init.d was turned off. Once I did a "chkconfig --level=2345 network on", things began working as expected.
(In reply to comment #13) > Probably more kernel-related; NM shouldn't care about the amount of memory, but > the drivers might care. There have been bugs historically with broadcom wifi > cards having issues with > 2G or 3G, I forget which. It is a Marvell Yukon Ethernet in my case.
I have submitted bug report https://bugzilla.redhat.com/show_bug.cgi?id=447489
Should this bug status be changed to Duplicate/clone of #447489 ? Cheers Balaji
My vote is no. Although his bug may be a duplicate/clone of this one. His bug is highly specific, and may be a subset of this one.
Installed from yum upgrade from Fedora 9 x86_64. Initial install was fine but had to disable Network Manager. After doing the initial yum update, install went fine but then on reboot "no network connection" tried using system -> network to configure the properties. Entered all info still no connection after saving and restarting network. Proceeded to /etc/sysconfig/network-scripts and noticed that there was no ifcfg-eth0 only ifcfg-lo. So created ifcfg-eth0 with vi after saving in the network came up. cycled network #service network restart error messase saying "could not bind <ip address> to eth0" network went down. Went back to terminal # cat ifcfg-eth0 network mask changed to the static ip address that was entered e.g.-netmask and ip address were the same. changed back with vi after saving network came back up. again recycle network again failure no error message this time. Opened ifcfg-eth0 again netmask had changed to same as ip address. Also anytime that you try to configure it with the Network GUI the ifcfg-eth0 file looks like a mixer has been through it with all entries the same ip address e.g.- ipaddr, netmask,gateway. This could not be fixed in Kernel 2.6.27.5-117.fc10.x86_64 so no connection to post bug from there. reverted back to 2.6.25-14.fc9.x86_64. Again initial install and configuration of yum upgrade all was well until reboot then no network connection. tried reinstalling twice once again from yum upgrade and one from CD both downloaded from the ANL mirrorsite.
Is the original problem still an issue with latest NM and kernel updates?
(In reply to comment #20) > Is the original problem still an issue with latest NM and kernel updates? Alas yes. Worse, there is a regression case where gdm will not start with 4GB RAM support enabled (the screen will turn black after plymouth completed loading services at startup). See attachment called boot_messages where some odd reason: etho (with is Marvell Ethernet) deactivated itself: Feb 20 10:35:48 kwetu NetworkManager: <info> Device 'eth0' DHCP transaction took too long (>45s), stopping it. Feb 20 10:35:48 kwetu NetworkManager: <info> eth0: canceled DHCP transaction, dhcp client pid 2599 Feb 20 10:35:48 kwetu NetworkManager: <info> Activation (eth0) Stage 4 of 5 (IP Configure Timeout) scheduled... Feb 20 10:35:48 kwetu NetworkManager: <info> Activation (eth0) Stage 4 of 5 (IP Configure Timeout) started... Feb 20 10:35:48 kwetu NetworkManager: <info> (eth0): device state change: 7 -> 9 Feb 20 10:35:48 kwetu NetworkManager: <info> Marking connection 'System eth0' invalid. Feb 20 10:35:48 kwetu NetworkManager: <info> Activation (eth0) failed. Feb 20 10:35:48 kwetu NetworkManager: <info> Activation (eth0) Stage 4 of 5 (IP Configure Timeout) complete. Feb 20 10:35:48 kwetu NetworkManager: <info> (eth0): device state change: 9 -> 3 Feb 20 10:35:48 kwetu NetworkManager: <info> (eth0): deactivating device (reason: 0) skge is still the issue found on bug #447489. BIOS for GA-K8NSC-939 was upgraded where the same problem occurred. I made an effort to contact Gigabyte manufacturers about the issue confirming a kernel issue. I compared with Microsoft Windows XP 64 bits and the problem was resolved with the latest driver from Marvell. It will be nice for either NM or Kernel team to contact Gigabyte Technologies as they appears to be very friendly to FOSS.
Created attachment 332745 [details] boot report from Fedora 10
Does the device still fail to get a DHCP address if you execute the following command (as root): /sbin/dhclient -1 -d -v eth0 (Ctrl+C to kill it after about a minute or two)
Result: # /sbin/dhclient -1 -d -v eth0 Internet Systems Consortium DHCP Client 4.0.0 Copyright 2004-2007 Internet Systems Consortium. All rights reserved. For info, please visit http://www.isc.org/sw/dhcp/ Listening on LPF/eth0/00:14:85:1f:51:8b Sending on LPF/eth0/00:14:85:1f:51:8b Sending on Socket/fallback DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 5 DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 14 DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 12 DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 20 DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 10 No DHCPOFFERS received. Unable to obtain a lease on first try. Exiting. Tested with 4GB RAM support enabled on Fedora 10. Disregard gdm issue on comment #20 as it turned out to be nvidia from RPMFusion, nouveau driver did not have that problem.
Tested with newly installed Fedora 11 Leonidas with kernel 2.6.29.4-167.fc11.x86_64, here is the result # /sbin/dhclient -1 -d -v eth1 Internet Systems Consortium DHCP Client 4.1.0 Copyright 2004-2008 Internet Systems Consortium. All rights reserved. For info, please visit http://www.isc.org/sw/dhcp/ Listening on LPF/eth1/00:14:85:1f:51:8b Sending on LPF/eth1/00:14:85:1f:51:8b Sending on Socket/fallback DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 8 DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 13 DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 21 DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 16 DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 3 No DHCPOFFERS received. Unable to obtain a lease on first try. Exiting. Same issue with the same Marvell Yukon Ethernet on the same motherboard.
Still no dice with Fedora 12 Alpha Aug 26 01:36:12 rawhide dhclient: Internet Systems Consortium DHCP Client 4.1.0p1 Aug 26 01:36:12 rawhide dhclient: Copyright 2004-2009 Internet Systems Consortium. Aug 26 01:36:12 rawhide dhclient: All rights reserved. Aug 26 01:36:12 rawhide dhclient: For info, please visit http://www.isc.org/sw/dhcp/ Aug 26 01:36:12 rawhide dhclient: Aug 26 01:36:12 rawhide NetworkManager: <info> DHCP: device eth1 state changed normal exit -> preinit Aug 26 01:36:12 rawhide dhclient: Listening on LPF/eth1/00:14:85:1f:51:8b Aug 26 01:36:12 rawhide dhclient: Sending on LPF/eth1/00:14:85:1f:51:8b Aug 26 01:36:12 rawhide dhclient: Sending on Socket/fallback Aug 26 01:36:14 rawhide dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 7 Aug 26 01:36:21 rawhide dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 10 Aug 26 01:36:31 rawhide dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 14 Aug 26 01:36:45 rawhide dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 14 Aug 26 01:36:57 rawhide NetworkManager: <info> (eth1): DHCP transaction took too long, stopping it. Aug 26 01:36:58 rawhide NetworkManager: <info> (eth1): canceled DHCP transaction, dhcp client pid 2224 Aug 26 01:36:58 rawhide NetworkManager: <info> Activation (eth1) Stage 4 of 5 (IP4 Configure Timeout) scheduled... Aug 26 01:36:58 rawhide NetworkManager: <info> Activation (eth1) Stage 4 of 5 (IP4 Configure Timeout) started... Aug 26 01:36:58 rawhide NetworkManager: <info> (eth1): device state change: 7 -> 9 (reason 5) Aug 26 01:36:58 rawhide NetworkManager: <info> Marking connection 'System eth1' invalid. Aug 26 01:36:58 rawhide NetworkManager: <info> Activation (eth1) failed. Aug 26 01:36:58 rawhide NetworkManager: <info> Activation (eth1) Stage 4 of 5 (IP4 Configure Timeout) complete. Aug 26 01:36:58 rawhide NetworkManager: <info> (eth1): device state change: 9 -> 3 (reason 0) Aug 26 01:36:58 rawhide NetworkManager: <info> (eth1): deactivating device (reason: 0).
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Is this still an issue? It seems more and more like driver issues. If anyone can get another machine on the segment and start up wireshark, we could find out if the machine that has problems is actually getting the DHCP requests out on the wire. If it's not, then the kernel is likely the culprit. If it does get the requests out, does the DHCP server respond?
Alas yes, it is still an issue. Here is the result: # /sbin/dhclient -1 -d -v eth1 Internet Systems Consortium DHCP Client 4.1.0p1 Copyright 2004-2009 Internet Systems Consortium. All rights reserved. For info, please visit http://www.isc.org/sw/dhcp/ Listening on LPF/eth1/00:14:85:1f:51:8b Sending on LPF/eth1/00:14:85:1f:51:8b Sending on Socket/fallback DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 4 DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 11 DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 11 DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 8 DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 16 DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 11 No DHCPOFFERS received. Unable to obtain a lease on first try. Exiting. I also think this is kernel issue too since Fedora 9. Perhaps somebody should poke kernel developer to solve that problem and merge #447489.
Yeah, I think this is a direct result of the bug. As such, I'm going to make it a duplicate of that. If the kernel bug is fixed then this bug should get fixed. *** This bug has been marked as a duplicate of bug 447489 ***