Bug 465442 - Network doesn't start after system restart
Summary: Network doesn't start after system restart
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: 9
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Dan Williams
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-10-03 11:03 UTC by Fred New
Modified: 2009-04-01 18:29 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-10-06 15:45:31 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
/var/log/messages for today, two system restarts (96.11 KB, text/plain)
2008-10-03 11:03 UTC, Fred New
no flags Details

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.


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