Bug 507351 - network management seems to "forget" eth0 settings for Marvell card
network management seems to "forget" eth0 settings for Marvell card
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-06-22 09:32 EDT by John Perry
Modified: 2010-06-10 00:55 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-06-10 00:55:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
copy of ifcfg-eth0 when NM failed (198 bytes, text/plain)
2009-07-01 22:05 EDT, John Perry
no flags Details
copy of /var/log/messages when NM failed (849.08 KB, text/plain)
2009-07-01 22:06 EDT, John Perry
no flags Details

  None (edit)
Description John Perry 2009-06-22 09:32:31 EDT
Description of problem:
After an update two weeks ago, NetworkManager stopped bringing up the network. Disabling NM and switching to the network service succeeded in fixing the problem.

After an update last week, the network service quit working, too. It was goofy: ifup eth0 sat there a few seconds, then reported failure. No ping, no nothing.

After a bit of meddling, I created in system-config-network a new eth0 profile (eth0_0) that was identical to the profile for the old eth0, which still showed up in system-config-network but not somewhere else. After checking "managed by NetworkManager" this started working with NM again. Deleted the old eth0, renamed eth0_0 to eth0, and things still appeared to be working.

Next day: quit working again (no update this time). Disabled NM & enabled network service, now running again. I worry it will fail again.

Version-Release number of selected component (if applicable):
Does this apply?

How reproducible:
Beats me. After the first two failures I thought the updates to Fedora x86_64 were breaking the network, but I have read online that the NIC driver is problematic in Linux (Marvell 88E8071).

Steps to Reproduce:
Actual results:
Network does not start.

Expected results:

Additional info:
I still suspect an update to Fedora broke this, but I don't know which. I'd be happy to assist with any debugging that might resolve this.
Comment 1 Niels Haase 2009-06-22 19:46:48 EDT
Thanks for filling this bug. 

To get a better feeling about your situation, can you please provide the below informations?

Version of kernel: uname -r
Version of NM: rpm -q NetworkManager
ls /etc/sysconfig/network-scripts/*ifcfg
your current used ifcfg file (from the dir above)
and the /var/log/messages after the problem occur.

But please keep in mind, that NM and s-c-n are different components. So please "stay" at NM to help with this bug. Thanks

Fedora Bugzappers volunteer triage team
Comment 2 John Perry 2009-06-23 00:53:34 EDT
NM:     NetworkManager-0.7.1-4.git20090414.fc11.x86_64

$ ls /etc/sysconfig/network-scripts/*ifcfg
ls: cannot access /etc/sysconfig/network-scripts/*ifcfg: No such file or directory

Maybe you meant this?
$ ls /etc/sysconfig/network-scripts/ifcfg*
/etc/sysconfig/network-scripts/ifcfg-eth0  /etc/sysconfig/network-scripts/ifcfg-lo


I will send the error message in a followup. This is while s-c-n is running, because otherwise I can't use the network to report this bug :-/
Comment 3 John Perry 2009-06-23 00:58:54 EDT
Argh. It decided to start working now. I'll update when it fails, but it might be a few days or so.

If a couple of weeks pass and it still doesn't fail, I'll tell everyone you guys are geniuses ;-)
Comment 4 John Perry 2009-07-01 22:04:47 EDT
NM refused to work again this morning. I have copied ifcfg-eth0 and /var/log/messages, and will upload them in a moment.
Comment 5 John Perry 2009-07-01 22:05:46 EDT
Created attachment 350237 [details]
copy of ifcfg-eth0 when NM failed
Comment 6 John Perry 2009-07-01 22:06:39 EDT
Created attachment 350238 [details]
copy of /var/log/messages when NM failed
Comment 7 Dan Williams 2009-11-11 20:08:19 EST
Hmm, that log shows:

Jul  1 21:00:12 quattrostelle dhclient: DHCPDISCOVER on eth0 to port 67 interval 5
Jul  1 21:00:17 quattrostelle dhclient: DHCPDISCOVER on eth0 to port 67 interval 13
Jul  1 21:00:30 quattrostelle dhclient: DHCPDISCOVER on eth0 to port 67 interval 15
Jul  1 21:00:45 quattrostelle dhclient: DHCPDISCOVER on eth0 to port 67 interval 20
Jul  1 21:00:55 quattrostelle NetworkManager: <info>  Device 'eth0' DHCP transaction took too long (>45s), stopping it.

If you get that happening again, can you drop to a root terminal and:

dhclient -1 -v eth0

and let that run and see what it does?  To me it looks like your DHCP server isn't responding; that could be either a kernel issue or a network issue or even an NM issue.  What kernel version are you running too?
Comment 8 Dan Williams 2009-11-11 20:10:26 EST
https://bugzilla.redhat.com/show_bug.cgi?id=507456 looks suspiciously similar.  Could you try a 'yum upgrade kernel NetworkManager dhclient' as well just to see if the updates fix the issue like bug 507456 mentions?
Comment 9 Bug Zapper 2010-04-27 11:09:33 EDT
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  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 '11'.

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 11'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 11 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: 
Comment 10 Dan Williams 2010-06-10 00:55:08 EDT
Closing due to lack of response; if the updates mentioned in comment 8 dont' help, please re-open this bug.  Thanks!

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