Description of problem:
Using the rawhide daily build boot.iso, NetworkManager fails with error 'An error occurred trying to bring up the eth0 network interface'.
Version-Release number of selected component (if applicable):
rawhide ppc build 15-Sep-2009 08:23
Steps to Reproduce:
1. boot with boot.iso CD
2. use GUI ot text install
2. installer stops with NetworkManager error message
This was working a few weeks ago, but now doesn't.
Running 'dhclient eth0' from tty2 after NetworkManager fails works OK (an IP is assigned to eth0), and the eth0 interface work OK.
Created attachment 361400 [details]
Created attachment 361401 [details]
Thanks for filling this bug. Since I'm not able to reproduce this kind of failure (missing hardware), can you please so kind to re-test it again with a more recent version of rawhide to see if the problem is still present. Thank you.
Fedora Bugzappers volunteer triage team
I tested today's (09-Oct-2009 11:30) rawhide build on PS3 and this problem has not been fixed.
I tried to figure out what was wrong, but couldn't make much progress. nm-tool is not available in the anaconda image.
This is the contents of ifcfg-eth0 before anaconda's 'Enable network interface' dialog:
And this is the contents after the 'Error configuring network device' message is seen:
# Network Interface
What can I do?
I tested today's (15-Oct-2009 07:29) rawhide build on PS3 and this problem has
not been fixed.
The only way we fix these sorts of things right now is more debugging in NM. Geoff, are you able to rebuild NM at all with some patches? Otherwise I can add some stuff and do some koji builds that you could try.
<29>Jul 28 19:09:18 NetworkManager: ifcfg-rh: updating /etc/sysconfig/network-scripts/ifcfg-eth0
<29>Jul 28 19:10:29 NetworkManager: <info> (eth0): carrier now ON (device state 1)
These show that ifcfg-rh is still able to read the configuration, but for whatever reason NM is not allowed to apply that configuration to the device when the carrier switches to ON. That could be because ONBOOT is not correctly read (or due to inotify sequence issues or something) or because the MAC address that NM reads with SIOCGIFHWADDR isn't the same as what the ifcfg file has, or something.
Or maybe there's an endian bug in NM somewhere.
on IRC we figured out that since the PS3 eth0 and wlan0 MAC address is the same, that NM will ignore the eth0 device as unmanaged even when ifcfg-eth0 flips to NM_CONTROLLED=yes, because the ifcfg-wlan0 file still has NM_CONTROLLED=no, and the manage/unmanaged decision is based on MAC address. I guess we need to also base the decision on device type.
I tried F-12 beta, and any fix for this problem was not included.
That's unfortunate, given that it's a regression and it's so simple to fix.
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.
More information and reason for this action is here:
I get the same problem during a fresh installation of Fedora 13 x86_64 on an HP Touchsmart 300.
On the page where it sets up the repositories, if you select one of the repositories, it brings up a popup:
Enable network interface
Interface eth0 - E0:CB:4E:A8:10:27
[x] Use dynamic IP configuration (DHCP)
[x] Enable IPv4 support
Sending request for IP address information for eth0
After about a minute it says:
An error occurred trying to bring up the eth0 network interface.
The computer came with Windows 7, and it can connect to the network, so the hardware is fine.
Steve, this bug is specifically about PS3 unmanaged devices, it seems the bug you have is different. Can you file a new bug so we can follow up?
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '12'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 12's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 12 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.