Bug 596884 - RHEL setup sets ifcfg-eth0 NM_CONTROLLED=no, causes disabled ethernet networking
RHEL setup sets ifcfg-eth0 NM_CONTROLLED=no, causes disabled ethernet networking
Status: CLOSED DUPLICATE of bug 606745
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: anaconda (Show other bugs)
6.0
All Linux
low Severity medium
: rc
: ---
Assigned To: Anaconda Maintenance Team
Release Test Team
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-27 13:34 EDT by Kai Engert (:kaie)
Modified: 2010-06-24 04:35 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-06-24 04:35:34 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)
dmesg (gz) (12.77 KB, application/octet-stream)
2010-05-27 13:46 EDT, Kai Engert (:kaie)
no flags Details
/var/log/messages (gz) (60.14 KB, application/octet-stream)
2010-05-27 13:46 EDT, Kai Engert (:kaie)
no flags Details
lsusb, lspci, lspci -n (3.09 KB, text/plain)
2010-05-27 13:48 EDT, Kai Engert (:kaie)
no flags Details

  None (edit)
Description Kai Engert (:kaie) 2010-05-27 13:34:11 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


How reproducible:
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


I tried
  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.
Comment 2 Kai Engert (:kaie) 2010-05-27 13:46:04 EDT
Created attachment 417322 [details]
dmesg (gz)
Comment 3 Kai Engert (:kaie) 2010-05-27 13:46:27 EDT
Created attachment 417323 [details]
/var/log/messages (gz)
Comment 4 Kai Engert (:kaie) 2010-05-27 13:48:25 EDT
Created attachment 417325 [details]
lsusb, lspci, lspci -n
Comment 5 Kai Engert (:kaie) 2010-05-27 13:55:26 EDT
FWIW, tried fedora 13 live usb stick, and wired networking works automatically
Comment 6 Matt Carlson 2010-06-04 13:35:17 EDT
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[9716]:    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).
Comment 7 Kai Engert (:kaie) 2010-06-04 14:59:18 EDT
(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[9716]:    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.
Comment 8 John Feeney 2010-06-04 15:19:37 EDT
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?
Comment 9 Kai Engert (:kaie) 2010-06-04 17:19:20 EDT
I'm confused, because it works now as expected.

To reiterate:

- installing RHEL6.0-20100526.2-Workstation-i386-DVD1.iso
  to harddisk
  => 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
  RHEL6.0-20100526.2-Client-i386-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).
Comment 10 Kai Engert (:kaie) 2010-06-05 04:50:34 EDT
Progress:

I installed to harddisk (again).

File
  /etc/sysconfig/network-scripts/ifcfg-eth0
contains 
  NM_CONTROLLED=no

As soon as I edit the file and change it to
  NM_CONTROLLED=yes
network-manager immediately starts up the ethernet connection.

Which software produced the incorrect file ifcfg-eth0 ?
Anaconda?
Comment 11 Kai Engert (:kaie) 2010-06-05 05:04:48 EDT
FWIW, during setup, I didn't touch any of the network related buttons (used defaults).
Comment 12 RHEL Product and Program Management 2010-06-07 11:55:50 EDT
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
inclusion.
Comment 13 Dan Williams 2010-06-23 18:44:51 EDT
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
Comment 14 Radek Vykydal 2010-06-24 04:35:34 EDT
(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
> done    

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 ***

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