Bug 465442 - Network doesn't start after system restart
Network doesn't start after system restart
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-03 07:03 EDT by Fred New
Modified: 2009-04-01 14:29 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-10-06 11:45:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description Fred New 2008-10-03 07:03:25 EDT
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 18:33:55 EDT
Could you update to latest stable updates (svn4022.4) and see if that fixes the issue?  Thanks!
Comment 2 Fred New 2008-10-06 02:37:40 EDT
Yes, NetworkManager-0.7.0-0.11.svn4022.4.fc9.i386 fixes this problem.
Comment 3 Dan Williams 2008-10-06 11:45:31 EDT
great, thanks for testing
Comment 4 Aleksey Nogin 2009-04-01 14:05:51 EDT
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 14:07:06 EDT
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 14:29:01 EDT
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.