Red Hat Bugzilla – Bug 444214
Service network turned off by default after installing from live CD
Last modified: 2008-05-02 11:09:26 EDT
Description of problem:
After installing F9 from the preview live CD, network interfaces defined
by ifcfg-* files are not brought up unless NM handles them.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install F9 from preview live CD.
2. Reboot system.
No interfaces are brought up, at least not ethX, wlanX. Only after
logging in to GNOME, interfaces for which NM_CONTROLLED=yes is
present in their ifcfg file like in my ifcfg-wlan0, are handled by
NM and get active.
Interfaces for which ONBOOT=yes has been added to their ifcfg file,
are brought up during system boot.
'chkconfig --list network' returns "network 0:off 1:off 2:off 3:off
4:off 5:off 6:off". If these default settings have been adopted in
order to accomodate NM, then this choice is not the best one. I have
set up a static interface in order to connect a printer, and the
corresponding interface is not started. Moreover, in general you want
to have network interfaces active during start-up, e.g. to allow NTP to
execute ntpdate which requires network connectivity already at that point
and not only after logging in to GNOME.
Please attach your ifcfg files.
# nVidia Corporation CK804 Ethernet Controller
- after start-up, the printer connection can be activated by means of
executing 'ifup eth0'.
- after executing 'chkconfig network on' and rebooting the system,
network interfaces marked with ONBOOT=yes get activated during boot-up
You'll want to change the "NM_CONTROLLED=no" to NM_CONTROLLED=yes. Not sure
what's marking that in the first place... Did you change that, or was it like
that right after install?
No, because NM does not work for me, I had switched off NM completely,
and I had also disabled NM control in the ifcfg files.
I understand now that in contrast with DVD installs where NM is
disabled by default, and the network service is enabled by default,
these roles are commuted for the live CD and installs from the latter.
That said, after setting NM_CONTROLLED=yes in my active ifcfg-* file,
# nVidia Corporation CK804 Ethernet Controller
# Broadcom Corporation NetXtreme BCM5721 Gigabit Ethernet PCI Express
# Please read /usr/share/doc/initscripts-*/sysconfig.txt
# for the documentation of these parameters.
After executing 'chkconfig network off', 'chkconfig NetworkManager
on', and rebooting the system, the NM service reports to have
started correctly [Ok] but a moment later, NTP reports that
executing ntpdate failed. After logging into GNOME, there is no NM
applet. Executing 'service NetworkManger status' reports:
'NetworkManager dead but subsys locked'. After restarting NM by
executing 'service NetworkManager restart', NM applet appears in
the GNOME panel showing the wired network icon. Both wireless and
wired devices are checkmarked.
I can ping my printer at 192.168.0.192 connected to eth0 and see
the web page of my AP by entering http://192.168.1.1 but
/etc/resolv.conf is empty. I need to shut down eth0 in order to
connect to my AP and get DHCP/DNS set up correctly.
If the 'off' default of the network service is considered correct,
then this bug is rather about the start-up failure of NM. Feel
free to reassign in case it is a suplicate.
(In reply to comment #4)
> If the 'off' default of the network service is considered correct,
> then this bug is rather about the start-up failure of NM.
Well, and about the wrong handling of DHCP/DNS in presence of a static
wired connection, too, of course.
Regarding comment #5, bug 441951 and bug 443865 appear to be related
to this one. I see these messages
'fedora NetworkManager: <WARN> nm_hal_manager_new(): Could not
initialize connection to the HAL daemon.'
in /var/log/messages, too.
Had you put your DNS servers into DNS1, DNS2, DNS3, etc in the ifcfg file, NM
would then populate resolv.conf correctly...
- The DNS server info is usually expected to be retrieved from the
DHCP server. Why should it be specified explicitly when, moreover,
the ISP can change it anytime without prior notice? I had set
PEERDNS=no in ifcfg-eth0 but PEERDNS=yes in ifcfg-wlan0, so this
should be ok.
- From a practical point of view, it would be nice if nm-applet
changed to reflect the status of the last selected device. In the
present case, where both wired and wireless connections are active,
it's always the wired icon which is displayed whereas the wireless
level meter would be much more useful, and this happens even when
the latest connection was established with the wireless device.
Joachim: the DNS server info is in reference to comment #4, where you give the
example of a static connection for the wired device, and where you say "but
/etc/resolv.conf is empty". With a static configuration, that can be fixed by
adding DNS1...DNS3 to the ifcfg file for a system connection.
If you have a static configuration in ifcfg-eth0 you'll want to put DNS1..DNS3
there if you want to use that connections DNS servers. For wlan0, if you use
DHCP, NM should pick up the DNS servers from DHCP. If it does not, could you
attach /var/log/messages so I can see what's going on?
When resolv.conf is screwed up, what's the output of '/usr/bin/nm-tool'?
Created attachment 304030 [details]
Output to /var/log/messages after restarting NM
In comment #4, I had given all three ifcfg files including that for my
wireless connection to the outside world configured by DHCP. The static
eth0 connection is simply used to attach my printer which is using
HP JetDirect to my system. It seems that the problem stems from the NM
policy. Towards the end of the log file there is a line
'NetworkManager: <info> Policy set (eth0) as default device for
routing and DNS.'
Created attachment 304031 [details]
Output from nm-tool with active eth0 and wlan0
Cool! NetworkManager-0.7.0-0.9.2.svn3619.fc9 sets up DNS servers correctly
now. The policy entry in /var/log/messages has changed and rather reads
'NetworkManager: <info> Policy set (wlan0) as default device for
routing and DNS.'
The only remaining issue is that the attempt to adjust the system clock
still leads to the following message at boot-up:
'ntpdate: Synchronization with time server: [Failed]'
When NM is disabled and the network service enabled, then this operation
succeeds. New bug report? Apart from this minor issue, everything works
Hmm; what does the following commands report for you? It may be a case of
[dcbw@localhost ~]$ ls /etc/rc2.d/*Net*
[dcbw@localhost ~]$ ls /etc/rc3.d/*Net*
you'll note that my system is technically "messed up" because NM starts really
late and is killed really early. If yours is the same, try:
/sbin/chkconfig NetworkManager resetpriorities
/sbin/chkconfig haldaemon resetpriorities
This should make sure NM starts before ntpd.
This is how the scripts are (were) ordered on my system:
and this hasn't changed after executing the two commands suggested
in comment #23. Actually, they haven't made a difference. Btw, as
you see, it's not the NTP daemon which is affected. The ntpdate
service simply adjusts the system clock by executing a single
command, namely query the NTP server in order to avoid huge delays
which can hamper the NTP dameon running later on. With the network
service disabled, it still complains. Most users will never see
this, because this option is unchecked in system-config-date unless
to enable it deliberately.
The workaround to the remaining issue that I have chosen is to
enable the network service in addition to NM. This makes sure that
network interfaces are available very early, and I haven't observed
any negative interference with NM taking over afterwards. And ntpdate
actually succeeds to contact the NTP server when called.
Setting 'NETWORKWAIT' in /etc/sysconfig/network should solve your issue.
Following your suggestion in a post to fedora-devel, I have added
'NETWORKWAIT=1' to /etc/sysconfig/network. I hope this is what you
had in mind. A boot message 'Waiting for the network' appears after
the NM service has been started [which might have been present
before or not], but the call to ntpdate shortly after fails again.
I will reinstall the system from DVD and/or live CD media as soon
as it gets available (RC or final F9) to see it the issue persists
for the current package set.
Starting my system today after yesterday's rawhide ugrade, ntpdate
actually succeeds in querying the NTP server despite the network
service being disabled. Everything works now!
Right, the issue seems solved provided the necessary tweak
NETWORKWAIT=1 or some equivalent fix makes its way into rawhide.