Red Hat Bugzilla – Bug 596884
RHEL setup sets ifcfg-eth0 NM_CONTROLLED=no, causes disabled ethernet networking
Last modified: 2010-06-24 04:35:34 EDT
Description of problem:
Wired networking doesn't work in Lenovo S12 netbook.
Internal Broadcom BCM5906M, 14e4:1713
Version-Release number of selected component (if applicable):
RHEL 6 nightly 20100526.2, Workstation i386
Install to Netbook, boot up with ethernet cable plugged in or not (no difference).
Network Manager doesn't detect anything.
ifconfig => no eth0
lsmod |grep -i tg3 => loaded
mobprobe -r tg3; modprobe tg3
That succeeds and gives me an eth0, but still, Network Manager doesn't see eth0.
I did a manual "ifconfig eth0 ... netmask ..." command, succeeds.
The virbr0 interface was disturbing. After I "ifconfig virbr0 down", then "ping" over the wired interface succeeds.
But still, the state seems broken.
If I restart the NetworkManager service, the device eth0 is gone again.
Created attachment 417322 [details]
Created attachment 417323 [details]
Created attachment 417325 [details]
lsusb, lspci, lspci -n
FWIW, tried fedora 13 live usb stick, and wired networking works automatically
The tg3 driver seems to enumerate the 5906 in all cases just fine.
In the messages file, I see :
May 27 19:15:59 netkaie NetworkManager: ifcfg-rh: Ignoring connection 'System eth0' and its device because NM_CONTROLLED was false.
That's probably why the Network Manager doesn't see it.
Does the interface show up with 'ifconfig -a'? If so, that just means that the network scripts didn't automatically configure the device (and you wouldn't see the device with the normal 'ifconfig' command).
(In reply to comment #6)
> The tg3 driver seems to enumerate the 5906 in all cases just fine.
Does this mean you're sure it's not a kernel bug?
> In the messages file, I see :
> May 27 19:15:59 netkaie NetworkManager: ifcfg-rh: Ignoring connection
> 'System eth0' and its device because NM_CONTROLLED was false.
Yes, the attached /var/log/messages contains that line. Testing again today, however, I no longer get this line.
This is probably because I no longer have the file /etc/sysconfig/network-scripts/ifcfg-eth0 . Why? Because my earlier test was done using a full installation. The hardware has now received a permanent Fedora installation (which works fine).
So, in order to continue with testing this issue, I boot RHEL from a USB live stick (which probably explains why I no longer have that ifcfg-eth0 file).
> That's probably why the Network Manager doesn't see it.
Not sure whether your theory is right, because I no longer get a message saying NM_CONTROLLED is false, and it still doesn't work.
However, maybe the message is simply no longer been shonw, because I don't have a ifcfg-eth0 file?
Do you know which software module is responsible for setting it to the right value? Maybe that same component still sets it to the "not controlled" state?
> Does the interface show up with 'ifconfig -a'?
In the new environment (same hardware, booted from live stick), both "ifconfig" and "ifconfig -a" do list eth0 (but NetworkManager still doesn't see it).
> If so, that just means that the
> network scripts didn't automatically configure the device (and you wouldn't see
> the device with the normal 'ifconfig' command).
If you're convinced this isn't a kernel issue, we should assign this bug to the NetworkManager component.
So, since ifconfig shows eth0, can you get an ip address?
I assume Matt thought it wasn't a driver issue because there were no tg3 messages in dmesg etc. I) noticed that too but I didn't have access to a system with a 5906M to check it out. (But thanks Matt for the info.)
Once you get RHEL6 installed, would it be possible to access this system to see what the config files look like?
I'm confused, because it works now as expected.
- installing RHEL6.0-20100526.2-Workstation-i386-DVD1.iso
=> broken as described in the initial comments (up to comment 4)
(I'm sure the network cable was plugged in that old experiment,
because I was able to get a connection after I used
a manual ifconfig, as stated in comment 0)
- the experiments I did today (comment 7) were done with
the same code snapshot, a live iso
BUT => today the network cable was not plugged in
(I simply didn't expect it to work, given I was still using a snapshot from
the same day.)
- now I booted the live version with ethernet cable plugged in,
and ethernet works just fine!
It seems unlikely that there is a difference between install-to-disk and boot-live-iso, but I'm tempted to install to hard disk again (which unfortunately will involve opening the notebook and installing a different harddisk).
I installed to harddisk (again).
As soon as I edit the file and change it to
network-manager immediately starts up the ethernet connection.
Which software produced the incorrect file ifcfg-eth0 ?
FWIW, during setup, I didn't touch any of the network related buttons (used defaults).
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release. Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release. This request is not yet committed for
Ok, so here's the problem...
Anaconda writes out ifcfg files with NM_CONTROLLED=no to make NM ignore the interface until you actually configure networking, at which point we assume that you actually want to enable networking. That's all fine.
But if you install from the DVD and don't configure networking in the installer, you're left with NM_CONTROLLED=no in the ifcfg files after the installation is done. That's not fine.
I'd suggest for anaconda that either:
1) only use NM_CONTROLLED=no for interface configurations that NM doesn't yet support, if any, and instead set ONBOOT=no so that NM does not bring the device up automatically until needed
2) set NM_CONTROLLED=yes for all NM supported configurations before the installer exits, so that devices are managed by NM after the installation is done
(In reply to comment #13)
> I'd suggest for anaconda that either:
> 1) only use NM_CONTROLLED=no for interface configurations that NM doesn't yet
> support, if any, and instead set ONBOOT=no so that NM does not bring the device
> up automatically until needed
> 2) set NM_CONTROLLED=yes for all NM supported configurations before the
> installer exits, so that devices are managed by NM after the installation is
Yes, I am working on 1) (2) would silently change what user could have selected in "Configure Network").
*** This bug has been marked as a duplicate of bug 606745 ***