Bug 441596

Please try latest NM in koji/rawhide (svn3549).

Also, have you set up ifcfg files with system-config-network, and are those
connections set NM_CONTROLLED=yes?

NetworkManager will read your ifcfg files for wired & wireless and use those if
available, and those will persist across login/logout.

Tested with on machine upgraded from F8>F9beta>rawhide
and grabbed following from koji:
NetworkManager-0.7.0-0.9.2.svn3590.fc9.i386
NetworkManager-glib-0.7.0-0.9.2.svn3590.fc9.i386
NetworkManager-gnome-0.7.0-0.9.2.svn3590.fc9.i386

When booting, now eth0 wired:
- iptables activated during boot
- starts responding to ping as gdm {login screen} starts
- stays connected as I log in.
- stays connected as I log out.
- stays connected as I log in again.
So all looks OK.

Interestingly I have:
/etc/sysconfig/network-scripts/ifcfg-eth0.bak
-rw-r--r-- 1 root root 254 2008-04-25 05:50 

cat /etc/sysconfig/network-scripts/ifcfg-eth0.bak 
# Broadcom Corporation NetXtreme BCM5788 Gigabit Ethernet
DEVICE=eth0
ONBOOT=yes
BOOTPROTO=dhcp
HWADDR=00:17:a4:e5:5e:40
TYPE=Ethernet

ie: no "NM_CONTROLLED=yes"

# service network status
Configured devices:
lo davidtdesktop re_melb
Currently active devices:
lo eth0

This is also the same and OK on another machine that was updated
F8>F9preview>rawhide to NM svn3566.

on 0.9.2.svn3614.fc9.i386 and with NM_CONTROLL=yes. Should the network stay
connected if you are:
- in init 5
- ctrl-alt-F1
- login as user
- su -c '\sbin\telinit 3'   {or 2} ?

It didn't. 

Added NetworkManager to levels 234. Now, I can telinit 3 from gnome and network
stays up. telinit to 2 and network stays up.

Rebooting and appending 2 or 3 on the kernel line, has trouble:
/sbin/service NetworkManager status
NetworkManager dead but pid file exists

/sbin/service NetworkManager stop
/sbin/service NetworkManager restart gets it going, and it gets an address
within a five seconds, and responds to ping.

Like a different bug for that situation, or is that expected ?

David; latest koji builds here:

http://koji.fedoraproject.org/koji/buildinfo?buildID=47429

make NM active at runlevel 2.  You may need to reset priorities though with
chkconfig.  Is there any message in /var/log/messages about NM?  Did NM crash,
perhaps because HAL wasn't up yet?

Created attachment 304052 [details]
var/log/message indicating NM trouble bzip2ed

(In reply to comment #4)
> David; latest koji builds here:
Yes that's what I was using in comment #3

> make NM active at runlevel 2.
# chkconfig --list NetworkManager
NetworkManager	0:off	1:off	2:on	3:on	4:on	5:on	6:off

> You may need to reset priorities though with chkconfig.
# chkconfig NetworkManager resetpriorities

> Is there any message in /var/log/messages about NM?  Did NM crash,
> perhaps because HAL wasn't up yet?
Yes: I have added some extra debuginfos, and am about to try again, but here is
the log up2 this point: search for ** START **

Created attachment 304114 [details]
shows a boot with NM fail to start

note: I echoed a message >> to log at the point of service NetworkManager
start.

I see this weird console kit error during the network plug events:
Apr 29 22:51:52 davidtnotebook console-kit-daemon[2273]: WARNING: Couldn't read
/proc/3698/environ: Error reading file '/proc/3698/environ': No such process

It didn't crash with a backtrace like the previous attachment.

Based on some f-test-list discussion I tried:
# chkconfig haldaemon resetpriorities
# chkconfig NetworkManager resetpriorities

Now:
- NetworkManager doesn't start during normal boot.
- service NetworkManager restart says Failed, OK, OK
- service NetworkManager status
NetworkManager dead but pid file exists

- service haldaemon start, OK.
- service NetworkManager restart says Failed, OK, OK
Now Network manager icon appears and it does it's thing.

Any chance you could grab the /var/log/messages from that attempt?  If NM is
dead (but left a PID) it probably crashed, and we'd need to grab the log to try
to see where it crashed...

Also, which svn version is this?  Latest from koji (svn3623) or something before
that?

Created attachment 304306 [details]
A NM trace from messages.

# rpm -qa kerne\* Net\* dbu\* hal\*|sort
dbus-1.2.1-1.fc9.i386
dbus-debuginfo-1.2.1-1.fc9.i386
dbus-glib-0.74-6.fc9.i386
dbus-glib-debuginfo-0.74-6.fc9.i386
dbus-libs-1.2.1-1.fc9.i386
dbus-python-0.82.4-2.fc9.i386
dbus-qt-0.70-4.fc9.i386
dbus-x11-1.2.1-1.fc9.i386
hal-0.5.11-0.7.rc2.fc9.i386
hal-cups-utils-0.6.16-3.fc9.i386
hal-debuginfo-0.5.11-0.7.rc2.fc9.i386
hal-info-20080317-6.fc9.noarch
hal-libs-0.5.11-0.7.rc2.fc9.i386
kernel-2.6.24.5-85.fc8.i686
kernel-2.6.25-8.fc9.i686
kernel-devel-2.6.24.5-85.fc8.i686
kernel-devel-2.6.25-8.fc9.i686
kernel-headers-2.6.25-8.fc9.i386
kerneloops-0.10-11.fc9.i386
NetworkManager-0.7.0-0.9.3.svn3623.fc9.i386
NetworkManager-debuginfo-0.7.0-0.9.3.svn3623.fc9.i386
NetworkManager-glib-0.7.0-0.9.3.svn3623.fc9.i386
NetworkManager-gnome-0.7.0-0.9.3.svn3623.fc9.i386
[root@davidtnotebook log]# rpm -Va kerne\* Net\* dbu\* hal\*|sort
[root@davidtnotebook log]# sestatus
SELinux status: 		enabled
SELinuxfs mount:		/selinux
Current mode:			enforcing
Mode from config file:		enforcing
Policy version: 		22
Policy from config file:	targeted

disclaimer: I have been renaming my var/log/messages, before restarting my
notebook. But quite often the clock keeps getting screwed. I can't be 100% sure
that the versions above were active when the preceding NetMan oops occured.

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Should be long-fixed; if the connection is a system connection from an ifcfg file, NM will honor it before login.