Bug 444214 - Service network turned off by default after installing from live CD
Service network turned off by default after installing from live CD
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
rawhide
x86_64 Linux
low Severity low
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-25 15:49 EDT by Joachim Frieben
Modified: 2008-05-02 11:09 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-02 10:43: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)
Output to /var/log/messages after restarting NM (9.06 KB, text/plain)
2008-04-28 15:20 EDT, Joachim Frieben
no flags Details
Output from nm-tool with active eth0 and wlan0 (1.47 KB, text/plain)
2008-04-28 15:31 EDT, Joachim Frieben
no flags Details

  None (edit)
Description Joachim Frieben 2008-04-25 15:49:48 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):
initscripts-8.72-1

How reproducible:
Always.

Steps to Reproduce:
1. Install F9 from preview live CD.
2. Reboot system.
  
Actual results:
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.

Expected results:
Interfaces for which ONBOOT=yes has been added to their ifcfg file,
are brought up during system boot.

Additional info:
'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.
Comment 1 Bill Nottingham 2008-04-25 16:05:13 EDT
Please attach your ifcfg files.
Comment 2 Joachim Frieben 2008-04-26 05:37:06 EDT
# nVidia Corporation CK804 Ethernet Controller
DEVICE=eth0
TYPE=Ethernet
BOOTPROTO=static
HWADDR=XX:XX:XX:XX:XX:XX
ONBOOT=yes
IPADDR=192.168.0.1
NETMASK=255.255.255.0
USERCTL=no
PEERDNS=no
IPV6INIT=no
NM_CONTROLLED=no

Additional comments:
- 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
  as expected.
Comment 3 Dan Williams 2008-04-28 00:39:32 EDT
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?
Comment 4 Joachim Frieben 2008-04-28 10:09:10 EDT
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,
they read:

ifcfg-eth0: ---------------------------------------------
# nVidia Corporation CK804 Ethernet Controller
DEVICE=eth0
TYPE=Ethernet
BOOTPROTO=none
HWADDR=XX:XX:XX:XX:XX:XX
ONBOOT=yes
IPADDR=192.168.0.1
NETMASK=255.255.255.0
USERCTL=no
PEERDNS=no
IPV6INIT=no
NM_CONTROLLED=yes

ifcfg-eth1: ---------------------------------------------
# Broadcom Corporation NetXtreme BCM5721 Gigabit Ethernet PCI Express
DEVICE=eth1
TYPE=Ethernet
BOOTPROTO=none
HWADDR=XX:XX:XX:XX:XX:XX
ONBOOT=no
NM_CONTROLLED=no

ifcfg-wlan0: --------------------------------------------
# Please read /usr/share/doc/initscripts-*/sysconfig.txt
# for the documentation of these parameters.
TYPE=Wireless
DEVICE=wlan0
HWADDR=XX:XX:XX:XX:XX:XX
BOOTPROTO=dhcp
DHCP_HOSTNAME=fedora
ONBOOT=yes
USERCTL=no
PEERDNS=yes
IPV6INIT=no
ESSID=AP
CHANNEL=5
MODE=Managed
RATE=auto
NM_CONTROLLED=yes

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.
Comment 5 Joachim Frieben 2008-04-28 10:18:32 EDT
(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.
Comment 6 Joachim Frieben 2008-04-28 11:54:54 EDT
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.
Comment 7 Dan Williams 2008-04-28 12:02:51 EDT
Had you put your DNS servers into DNS1, DNS2, DNS3, etc in the ifcfg file, NM
would then populate resolv.conf correctly...
Comment 8 Joachim Frieben 2008-04-28 13:17:14 EDT
- 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.
Comment 9 Dan Williams 2008-04-28 13:45:39 EDT
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'?
Comment 10 Joachim Frieben 2008-04-28 15:20:39 EDT
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.'
Comment 11 Joachim Frieben 2008-04-28 15:31:18 EDT
Created attachment 304031 [details]
Output from nm-tool with active eth0 and wlan0
Comment 12 Joachim Frieben 2008-04-30 07:42:09 EDT
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
now :)
Comment 13 Dan Williams 2008-05-01 07:03:33 EDT
Hmm; what does the following commands report for you?  It may be a case of
initscript priority:

[dcbw@localhost ~]$ ls /etc/rc2.d/*Net*
/etc/rc2.d/K01NetworkManager  /etc/rc2.d/K02NetworkManagerDispatcher
[dcbw@localhost ~]$ ls /etc/rc3.d/*Net*
/etc/rc3.d/K02NetworkManagerDispatcher  /etc/rc3.d/S99NetworkManager
[dcbw@localhost ~]$ 

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.  
Comment 14 Joachim Frieben 2008-05-01 08:51:42 EDT
This is how the scripts are (were) ordered on my system:

/etc/rc2.d/S27NetworkManager@  /etc/rc4.d/S27NetworkManager@
/etc/rc3.d/S27NetworkManager@  /etc/rc5.d/S27NetworkManager@

/etc/rc2.d/S57ntpdate@  /etc/rc4.d/S57ntpdate@
/etc/rc3.d/S57ntpdate@  /etc/rc5.d/S57ntpdate@

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.
Comment 15 Bill Nottingham 2008-05-01 09:43:46 EDT
Setting 'NETWORKWAIT' in /etc/sysconfig/network should solve your issue.
Comment 16 Joachim Frieben 2008-05-01 11:38:29 EDT
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.
Comment 17 Joachim Frieben 2008-05-02 01:46:09 EDT
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!
Comment 18 Dan Williams 2008-05-02 10:43:31 EDT
Great, thanks!
Comment 19 Joachim Frieben 2008-05-02 11:09:26 EDT
Right, the issue seems solved provided the necessary tweak
NETWORKWAIT=1 or some equivalent fix makes its way into rawhide.

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