Bug 431941
Summary: | Fedora 9 Alpha : Internet NOT Working : Have to "Activate" eth0 After Each Boot | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Jags FL <jags_fl> | ||||||||
Component: | dhcp | Assignee: | David Cantrell <dcantrell> | ||||||||
Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
Severity: | urgent | Docs Contact: | |||||||||
Priority: | low | ||||||||||
Version: | 9 | CC: | dcbw, jmoskovc, lordmorgul, mleech, ondrejj, riku.seppala, wtogami, wwoods | ||||||||
Target Milestone: | --- | ||||||||||
Target Release: | --- | ||||||||||
Hardware: | i386 | ||||||||||
OS: | Linux | ||||||||||
Whiteboard: | |||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||
Doc Text: | Story Points: | --- | |||||||||
Clone Of: | Environment: | ||||||||||
Last Closed: | 2008-08-04 20:10:09 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: | |||||||||||
Attachments: |
|
Description
Jags FL
2008-02-07 22:41:02 UTC
Is the NetworkManager service running? A 'ps aux | grep Net' will tell you if it is, or "/sbin/service NetworkManager status". Can you give the output of /sbin/lscpi, (as root) '/sbin/ethtool eth0', and (as root) '/sbin/mii-tool eth0' ? Anyway, if you are not running NetworkManager, have you tried to check the "Activate device when computer starts" option in the properties window when you click on a device in the "Device" tab and click the Edit... button? I'm not original reporter but, since I have this same problem I'll answer for my part. NetworkManager is stopped Created attachment 294477 [details]
lspci
Settings for eth9: Supported ports: [ MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised auto-negotiation: Yes Speed: 100Mb/s Duplex: Full Port: MII PHYAD: 1 Transceiver: external Auto-negotiation: on Supports Wake-on: g Wake-on: d Link detected: yes [root@localhost tmp]# /sbin/mii-tool eth9 SIOCGMIIPHY on 'eth9' failed: Operation not supported Really dump question, where do I find networkmanager? I can get the networkmanager applet on the tray but, selecting "Edit connections..." does nothing. I have this problem working on a VMware guest system with two network adapters configured. One is set as a static IP and the other is configured by dhcp (served by the guest OS). Both are configured with ONBOOT=yes. The adapter with static ip has a NETWORKMANAGER=no, but the dhcp adapter did not. I'm testing whether this makes a difference in this situation (NetworkManager is chkconfig'd off). When I ifdown eth0; ifup eth0 it picks up a new dhcp address just fine, but it won't work on boot. Here is more of the info you'd asked for Dan. Also I've got a dmesg coming. The main problem (seen in the dmesg) may be the selinux audits that show up: type=1400 audit(1205217645.496:4): avc: denied { write } for pid=1700 comm="cp" name="resolv.conf.predhclient.eth0" dev=sda3 ino=426021 scontext=system_u:system_r:dhcpc_t:s0 tcontext=unconfined_u:object_r:etc_t:s0 tclass=file type=1400 audit(1205217645.496:5): avc: denied { unlink } for pid=1700 comm="cp" name="resolv.conf.predhclient.eth0" dev=sda3 ino=426021 scontext=system_u:system_r:dhcpc_t:s0 tcontext=unconfined_u:object_r:etc_t:s0 tclass=file I'll check this permissive in a minute. Created attachment 297569 [details]
dmesg-vmware-eth0.txt
Created attachment 297570 [details]
vmware-ifcfg-info-eth0.txt
This issue does not happen when booting with selinux permissive; eth0 receives dhcp configuration on boot. Using audit2allow produces this (for these denials): #============= dhcpc_t ============== allow dhcpc_t etc_t:file { write unlink }; allow dhcpc_t var_log_t:file append; Creating a module for these by: ausearch -m avc | grep dhcp | audit2allow -M mydhcp and loading by: semodule -i mydhcp.pp This does not work on reboot with enforcing, but it does work after inserting the module and then restarting the network service via telinit 1; telinit 3. This should probably be changed to an selinux bug. The vmxnet ethernet driver does not implement the 'ethtool_ops' interface that the kernel expects, and therefore calls like: /sbin/ethtool eth0 will fail to return correct values. This is one part of the equation; you'll have to get upstream VMWare to fix that issue and then install an updated vmxnet driver. The vmware tools and kernel modules are not installed on my system. Is this a recent change in expected behavior? Earlier rawhide kernels did not have this issue (the dhcp interfaces used to come up on boot just fine). For me this bug looks fixed, I'm not seeing it any more with Fedora 9 beta. I'm using Fedora 9 Preview, with all updates applied (as of this evening). I'm still seeing this problem. Here's an ethool dump for eth0: Settings for eth0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Advertised auto-negotiation: Yes Speed: 100Mb/s Duplex: Full Port: MII PHYAD: 1 Transceiver: internal Auto-negotiation: on Supports Wake-on: g Wake-on: g Current message level: 0x00000007 (7) Link detected: yes When I originally setup this interface in Anaconda, I had NetManager turned off, with static IP/DNS settings and "bring up interface at startup" set. It fails to come up on boot every time. I have to manually bring the interface up. Very annoying, since I'm targetting this to be a server tucked away in a cupboard. Here are messages relating to eth0: from dmesg: e100: eth0: e100_probe: addr 0x90010000, irq 20, MAC addr 00:19:d1:68:c5:4f ADDRCONF(NETDEV_UP): eth0: link is not ready e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready eth0: no IPv6 routers present My static network configuration works fine - this is a fresh install of current rawhide bits (F9 almost-RC). In most cases where the installed system was a pre-release version of F9 and static network configs are not working properly, it's because that version of F9 didn't write the proper things into ifcfg-ethX *or* had different startup priorities for the needed services ('network', 'NetworkManager', 'messagebus', 'hald', etc). Two things to try before reporting a bug: 1) make sure your network configuration has the right stuff in it A typical /etc/sysconfig/network-scripts/ifcfg-eth0 for a wired network on a fresh system will have: ONBOOT=yes NM_CONTROLLED= BOOTPROTO=[static/dhcp] [etc.] 2) make sure your network services are coming up in the right order. As root, do: for service in network messagebus haldaemon NetworkManager; do chkconfig $service resetpriorities; done You should also attach your ifcfg-ethX files to any further reports. Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Same problem for me on one laptop upgraded from F8 to F9 and one fresh install of F9. I think this is a duplicate of #447536 (my bug). My config: [root@somodi ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0 # Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller DEVICE=eth0 BOOTPROTO=dhcp HWADDR=00:19:db:00:00:8b IPV6INIT=yes IPV6_AUTOCONF=yes ONBOOT=yes DHCP_HOSTNAME=somodi.ciakt.xxxxx.sk SEARCH=xxxx.sk NM_CONTROLLED=no DNS2=1.197.16.30 TYPE=Ethernet DNS1=1.197.16.31 USERCTL=yes PEERDNS=yes PERSISTENT_DHCLIENT=y Same without PERSISTENT_DHCLIENT option. Static network works well, but dhcp network not. Also IPv6 is working well. dhclient is running after reboot, but no IPv4 address assigned to my interface. [root@somodi ~]# ps axw | grep dhclient 2005 ? Ss 0:00 /sbin/dhclient -q -cf /etc/dhclient-eth0.conf -lf /var/lib/dhclient/dhclient-eth0.leases -pf /var/run/dhclient-eth0.pid eth0 After service resetpriorities my problem looks to be solved. But why this is not default after a fresh installation? Second coputer tested again: NetworkManager must be running to get IPv4 address from DHCP when trying to do service netowork restart. There is no effect of NM_CONTROLLED= parameter for this. After uninstall of NetworkManager and a reboot it's working again properly. :-) There are 2 solutions for users (before fixes in packages): 1. Uninstall NetworkManager (yum remove NetworkManager -y) 2. When you need NetworkManager, be sure that: a) it is already running (chkconfig NetworkManager on) b) it has good priority (see above) Marking it as a duplicate of bug #447536 per comment #17 and comment #18. *** This bug has been marked as a duplicate of bug 447536 *** |