Bug 465442

Summary: Network doesn't start after system restart
Product: [Fedora] Fedora Reporter: Fred New <fred.new2911>
Component: NetworkManagerAssignee: Dan Williams <dcbw>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 9CC: aleksey, dcantrell, dcbw, wtogami, wwoods
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-10-06 15:45:31 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:
Attachments:
Description Flags
/var/log/messages for today, two system restarts none

Description Fred New 2008-10-03 11:03:25 UTC
Created attachment 319348 [details]
/var/log/messages for today, two system restarts

Description of problem:
I installed several updates to Fedora 9 this morning including the kernel and dhclient.  After restarting my system I was unable to SSH into my system.  Looking in /var/log/messages I see,

Oct  3 08:41:46 ruuttest NetworkManager: <WARN>  system_settings_get_unmanaged_devices_cb(): system_settings_get_unmanaged_devices_cb: Error getting unmanaged devices from the system settings service: (4) Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
Oct  3 08:41:46 ruuttest NetworkManager: <WARN>  list_connections_cb(): Couldn't retrieve connections: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken..
-----------
A little further down, I notice that NetworkManager restarted successfully when I logged into a Gnome session.  I'll attach the appropriate section of /var/log/messages.

-----------------------
Version-Release number of selected component (if applicable):
dhclient-4.0.0-18.fc9.i386
NetworkManager-0.7.0-0.11.svn4022.fc9.i386
kernel-2.6.26.5-45.fc9.i686

How reproducible:
Always


Steps to Reproduce:
1. Restart computer with the package versions mentioned above.
  
Actual results:
The network doesn't start correctly until I start a Gnome session.

Expected results:
A working network connection after the system restarts.

Additional info:
lspci for my NIC:
02:08.0 Ethernet controller: Intel Corporation 82801BA/BAM/CA/CAM Ethernet Controller (rev 03)

Comment 1 Dan Williams 2008-10-03 22:33:55 UTC
Could you update to latest stable updates (svn4022.4) and see if that fixes the issue?  Thanks!

Comment 2 Fred New 2008-10-06 06:37:40 UTC
Yes, NetworkManager-0.7.0-0.11.svn4022.4.fc9.i386 fixes this problem.

Comment 3 Dan Williams 2008-10-06 15:45:31 UTC
great, thanks for testing

Comment 4 Aleksey Nogin 2009-04-01 18:05:51 UTC
dhclient-3.0.5-18.el5
NetworkManager-0.7.0-3.el5
kernel-2.6.18-128.1.1.el5

Comment 5 Aleksey Nogin 2009-04-01 18:07:06 UTC
Sorry, something went wrong with my comment. I wanted to say - I am seeing this with RHEL 5.3 with

dhclient-3.0.5-18.el5
NetworkManager-0.7.0-3.el5
kernel-2.6.18-128.1.1.el5

Comment 6 Aleksey Nogin 2009-04-01 18:29:01 UTC
grep 'system[_-]settings' /var/log/messages    shows"

Apr  1 10:57:16 localhost nm-system-settings: initial_add_devices_of_type: could not get device from HAL: An SELinux policy prevents this sender from sending this message to this recipient (rejected message had interface "org.freedesktop.Hal.Manager" member "FindDeviceByCapability" error name "(unset)" destination "org.freedesktop.Hal") (9).
Apr  1 10:57:16 localhost nm-system-settings: initial_add_devices_of_type: could not get device from HAL: An SELinux policy prevents this sender from sending this message to this recipient (rejected message had interface "org.freedesktop.Hal.Manager" member "FindDeviceByCapability" error name "(unset)" destination "org.freedesktop.Hal") (9).
Apr  1 10:57:16 localhost nm-system-settings: initial_add_devices_of_type: could not get device from HAL: An SELinux policy prevents this sender from sending this message to this recipient (rejected message had interface "org.freedesktop.Hal.Manager" member "FindDeviceByCapability" error name "(unset)" destination "org.freedesktop.Hal") (9).
Apr  1 10:57:16 localhost nm-system-settings: Loaded plugin ifcfg-rh: (c) 2007 - 2008 Red Hat, Inc.  To report bugs please use the NetworkManager mailing list.
Apr  1 10:57:16 localhost nm-system-settings:    ifcfg-rh: parsing /etc/sysconfig/network-scripts/ifcfg-eth0 ...
Apr  1 10:57:16 localhost nm-system-settings:    ifcfg-rh:     read connection 'System eth0'
Apr  1 10:57:16 localhost nm-system-settings:    ifcfg-rh: parsing /etc/sysconfig/network-scripts/ifcfg-vzw ...
Apr  1 10:57:16 localhost nm-system-settings:    ifcfg-rh:     error: Unknown connection type 'Modem'
Apr  1 10:57:16 localhost nm-system-settings:    ifcfg-rh: parsing /etc/sysconfig/network-scripts/ifcfg-wlan0 ...
Apr  1 10:57:16 localhost nm-system-settings:    ifcfg-rh:     error: Missing SSID
Apr  1 10:57:16 localhost nm-system-settings:    ifcfg-rh: parsing /etc/sysconfig/network-scripts/ifcfg-lo ...
Apr  1 10:57:16 localhost nm-system-settings:    ifcfg-rh:     error: Ignoring loopback device config.
Apr  1 10:57:52 localhost NetworkManager: <WARN>  system_settings_get_unmanaged_devices_cb(): system_settings_get_unmanaged_devices_cb: Error getting unmanaged devices from the system settings service: (4) Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
Apr  1 10:57:52 localhost NetworkManager: <WARN>  system_settings_get_hostname_cb(): system_settings_get_hostname_cb: Error getting hostname from the system settings service: (4) Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

The interface that I expect to be up, but that is down until I log in is wlan0.