|Summary:||RHEL setup sets ifcfg-eth0 NM_CONTROLLED=no, causes disabled ethernet networking|
|Product:||Red Hat Enterprise Linux 6||Reporter:||Kai Engert (:kaie) (inactive account) <kengert>|
|Component:||anaconda||Assignee:||Anaconda Maintenance Team <anaconda-maint-list>|
|Status:||CLOSED DUPLICATE||QA Contact:||Release Test Team <release-test-team>|
|Version:||6.0||CC:||arozansk, jfeeney, mcarlson, rvykydal|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2010-06-24 08:35:34 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Kai Engert (:kaie) (inactive account) 2010-05-27 17:34:11 UTC
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) (inactive account) 2010-05-27 17:46:04 UTC
Created attachment 417322 [details] dmesg (gz)
Comment 3 Kai Engert (:kaie) (inactive account) 2010-05-27 17:46:27 UTC
Created attachment 417323 [details] /var/log/messages (gz)
Comment 4 Kai Engert (:kaie) (inactive account) 2010-05-27 17:48:25 UTC
Created attachment 417325 [details] lsusb, lspci, lspci -n
Comment 5 Kai Engert (:kaie) (inactive account) 2010-05-27 17:55:26 UTC
FWIW, tried fedora 13 live usb stick, and wired networking works automatically
Comment 6 Matt Carlson 2010-06-04 17:35:17 UTC
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).
Comment 7 Kai Engert (:kaie) (inactive account) 2010-06-04 18:59:18 UTC
(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.
Comment 8 John Feeney 2010-06-04 19:19:37 UTC
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) (inactive account) 2010-06-04 21:19:20 UTC
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) (inactive account) 2010-06-05 08:50:34 UTC
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) (inactive account) 2010-06-05 09:04:48 UTC
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 15:55:50 UTC
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 22:44:51 UTC
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 08:35:34 UTC
(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 ***