Bug 431941 - Fedora 9 Alpha : Internet NOT Working : Have to "Activate" eth0 After Each Boot
Fedora 9 Alpha : Internet NOT Working : Have to "Activate" eth0 After Each Boot
Status: CLOSED DUPLICATE of bug 447536
Product: Fedora
Classification: Fedora
Component: dhcp (Show other bugs)
9
i386 Linux
low Severity urgent
: ---
: ---
Assigned To: David Cantrell
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-07 17:41 EST by Jags FL
Modified: 2008-08-04 16:10 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-08-04 16:10:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
lspci (2.40 KB, text/plain)
2008-02-09 15:23 EST, Riku Seppala
no flags Details
dmesg-vmware-eth0.txt (24.01 KB, text/plain)
2008-03-11 03:01 EDT, Andrew Farris
no flags Details
vmware-ifcfg-info-eth0.txt (4.74 KB, text/plain)
2008-03-11 03:01 EDT, Andrew Farris
no flags Details

  None (edit)
Description Jags FL 2008-02-07 17:41:02 EST
I've just finished installing Fedora 9 Alpha (from i386 DVD) third time.

After all three installations, I've to "Activate" ethernet card / networking in
order to use Internet after each boot.

[ System > Administration > Network > Network Configuration > "eth0" status is
"Inactive" > after clicking green "Activate" button > Internet works just fine ]

During system boot I do see this message:

Determining IP information for for eth0... cp: cannot remove
'/etc/resolv.conf.predhclient' permission denied.
Done. [OK]

I don't know if that message have anything to do with "activation" of ethernet
card after each boot.


P.S.: In this Bug reporting in version options, there is NO option for Fedora 9
/ Fedora 9 Alpha
Comment 1 Dan Williams 2008-02-07 17:53:06 EST
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?
Comment 2 Riku Seppala 2008-02-08 07:18:22 EST
hmm... https://bugzilla.redhat.com/show_bug.cgi?id=324891
Comment 3 Riku Seppala 2008-02-09 15:22:01 EST
I'm not original reporter but, since I have this same problem I'll answer for my
part.

NetworkManager is stopped
Comment 4 Riku Seppala 2008-02-09 15:23:21 EST
Created attachment 294477 [details]
lspci
Comment 5 Riku Seppala 2008-02-09 15:35:31 EST
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.
Comment 6 Andrew Farris 2008-03-11 02:38:30 EDT
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.
Comment 7 Andrew Farris 2008-03-11 02:59:35 EDT
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.
Comment 8 Andrew Farris 2008-03-11 03:01:13 EDT
Created attachment 297569 [details]
dmesg-vmware-eth0.txt
Comment 9 Andrew Farris 2008-03-11 03:01:41 EDT
Created attachment 297570 [details]
vmware-ifcfg-info-eth0.txt
Comment 10 Andrew Farris 2008-03-11 03:27:24 EDT
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.
Comment 11 Dan Williams 2008-03-11 08:48:00 EDT
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.
Comment 12 Andrew Farris 2008-03-13 03:11:26 EDT
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).
Comment 13 Riku Seppala 2008-03-31 17:06:25 EDT
For me this bug looks fixed, I'm not seeing it any more with Fedora 9 beta.
Comment 14 Marcus D. Leech 2008-05-04 22:16:09 EDT
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


Comment 15 Will Woods 2008-05-05 17:49:55 EDT
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.
Comment 16 Bug Zapper 2008-05-14 01:04:03 EDT
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
Comment 17 Jan ONDREJ 2008-06-05 04:23:01 EDT
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?
Comment 18 Jan ONDREJ 2008-06-05 04:40:23 EDT
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)
Comment 19 David Cantrell 2008-08-04 16:10:09 EDT
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 ***

Note You need to log in before you can comment on or make changes to this bug.