Bug 442947
| Summary: | static wired eth0 disabled on boot when NM starts | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Thomas J. Baker <tjb> |
| Component: | NetworkManager | Assignee: | Dan Williams <dcbw> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | low | ||
| Version: | rawhide | CC: | dcbw, didierg-divers, gbillios+redhat, wtogami, zkabelac |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2008-04-23 19:52:57 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Thomas J. Baker
2008-04-17 19:17:22 UTC
I also see this behaviour - to get the network running on eht0 I had to run /etc/init.d/network restart After this command the NetworkMananger gets the IP address from DHCP server. This also happens to me for over a week as well. I also have to either restart network service or right click the nm applet, untick enable networking and tick it again! Could you run /usr/bin/nm-tool _before_ restarting NM and stick the output in this bug? Feel free to obfuscate any MAC addresses in the output. Not much to obfuscate:
[root@katratzi ~]# nm-tool
NetworkManager Tool
State: disconnected
- Device: eth0 ----------------------------------------------------------------
Type: Wired
Driver: e1000
State: unavailable
HW Address: 00:00:00:00:00:00
Capabilities:
Supported: yes
Carrier Detect: yes
Speed: 1000 Mb/s
Wired Settings
[root@katratzi ~]# exit
Is the 'network' service supposed to be chkconfig'd on or not? I noticed that my problem system had it on. I just turned it off and rebooted and now the network came up fine (aside from ypbind). I could add these things: When I start to the system and the applet shows unconnected state I also get also the output same as tjb. When I turn the network Off/On The State: is changed from unavailable -> unmanaged -> disconnected -> connected Also when I've placed the nm-tool >/tmp/log in front of /etc/init.d/NetworkManager I get this output: " ** (process:2678): WARNING **: nm_object_get_property: Error getting 'WirelessHardwareEnabled' for /org/freedesktop/NetworkManager: The name org.freedesktop.NetworkManager was not provided by any .service files NetworkManager appears not to be running (could not get its state). NetworkManager Tool State: unknown " And the most interesting fact is - when I put there 'exit 0' as the first line of this /etc/init.d/NetworkManager script - the network is actually running properly right after the reboot ;) Can you try with the latest NM in koji? http://koji.fedoraproject.org/koji/buildinfo?buildID=46621 Please include the output of both /usr/bin/nm-tool and /var/log/messages for the time when it does _not_ work. I'm beginning to think this may be a f9beta + a month of rawhide cruft build-up problem. I've got another system that had the preview clean installed last Friday and it works fine in a very similar setup. Unless you want to continue testing this specific system, I'd like to just install from rawhide and see what happens with that. I could then try those koji builds. I tried those NM builds which may have fixed it but I've got another problem now that is probably cruft related. In tracking down another bug (https://bugzilla.redhat.com/show_bug.cgi?id=443409) I reset the priorities of haldaemon and NetworkManager. Now when this system boots haldaemon fails to start which breaks NM too. After boot, if I log in as root and restart haldaemon then NM, things work as expected. So I think the problem is fixed for me, but I won't know for sure until I do a clean install. With a clean install this morning from rawhide, everything seems to be working correctly, even with the svn3566 version of NM. Not sure how things got so messed up. I update to rawhide daily and reboot after each update. ok; closing I don't think this bug should be closed. So a fresh installation doesn't present this bug, but an older installation *with* the current updates does. Don't you worry that what caused this problem might still trigger a new bug if the problem is pinpointed? For example after a suggestion in this bug, I turned of the network service and this bug disappeared. Is this the correct solution? Should the network service be disabled? FWIW, on all my preview installed systems, network is turned off by default and things work as expected. In terms of closing the bug, I think that if things are working from a current install (can't say about an update from F8 to F9) then closing it is best. Given that there are only so many hours in a day, is it really worth holding up F9 chasing down a bug that only happens to beta testers who are updating many packages everyday for weeks? All it takes is one slightly bad install script from one testing version of a package to put the system into an unexpected state. No disrespect intended. Personally I still believe there is a bug in Network Manager - thought might be I do not know how this thing is supposed to work. Anyway - for me the 'good enough' fix is - to remove: ~/.gconf/system/networking/connection directory and set the parameter ONBOOT=no in the file /etc/sysconfig/network-scripts/ifcfg-eth0 So doing fresh reinstall of the Fedora is an overkill... Still I'll most probably had to figure out why am I asked many times for the access key for the wifi WEP key - when the eth0 connection is accessible - but as I can see, I'll most probably had to figure this all myself, to save many hours in a day :) Zdenek: NM brings up any available device (it supports multiple active netowrk devices) that's either configured in the user's settings, or marked ONBOOT=yes in the ifcfg files. You'll be asked at least for your keyring password so NM can access your WEP keys and WPA passphrases. If the AP rejects your connection or it times out, NM will ask you for the password again. Hmm - I'm pretty sure it used to work in a very nice way before - i.e. when it was connected to Wired network - it was not trying to gain access to WEP network. When I unplugged my notebook from docking station - it has nicely tried to get access to rhn - and asked for the password at this time. At my home where I do not have rhn, but I've home network without any encryption, it also did not asked for password. However now - I'm always asked for password for keywallet - and even thought I'm pretty sure the RHN wep key is properly entered - Network Manager is not able to access RHN - unless I try several times to variate between 128bit key & 40hex/128bit key (which should be correct - but it's not somehow remembered by NM) - when I do not want to enter password (i.e. Deny/or cancel via Esc) I'm asked with the same dialog again for 5 times - most probably to make sure I really do not want to enter the password ;) Next point is - I could not actually even turn off AutoConnect switch in the EditConnection anyway (I think this GUI is actually not storing its data properly which might be the whole reason for the bug) Next thing would be that whole NM actually eats around 10M - what for ? this should be also probably fixed. Also I sais - with ONBOOT=yes for eth0 NM actually unconnects eth0 (as I could see in the message log) Simply I'd like to see the good old behaviour ;) |