Bug 465977 - PXE boot - unable to bring up network
PXE boot - unable to bring up network
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F10Blocker/F10FinalBlocker
  Show dependency treegraph
 
Reported: 2008-10-07 11:01 EDT by Orion Poplawski
Modified: 2008-10-16 18:14 EDT (History)
4 users (show)

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


Attachments (Terms of Use)

  None (edit)
Description Orion Poplawski 2008-10-07 11:01:06 EDT
Description of problem:

PXE boot, ks=nfs

INFO: only have one network device: eth0
ERROR: failed to start NetworkManager (9)
ERROR: unable to bring up network

nm-system-settings: ifcfg-fedora: error: Invalid IP4 prefix '0'
nm-system-settings: ifcfg-fedora: parsing /etc/sysconfig/network-scripts/ifcfg-eth0
...
NetworkManager: <info> (eth0): device state change: 2 -> 3
(last message)

No dhcp requests arrive at the server.

Version-Release number of selected component (if applicable):
11.4.1.44
Comment 1 Orion Poplawski 2008-10-10 13:46:16 EDT
Put in some debugging and ifcfg-eth0 should be good:

DEVICE=eth0
HWADDR=00:19:D1:04:01:2D
ONBOOT=yes
NM_CONTROLLED=

So what's up with the nm-system-settings error?
Comment 2 Orion Poplawski 2008-10-10 14:07:17 EDT
Okay, looks like the nm-system-settings error may be a red herring - seeing
that on lots of machines.  So why doesn't NM bring up the device?
Comment 3 Orion Poplawski 2008-10-10 17:22:29 EDT
The fix I suggested in bug #462083 was to start NM after ifcfg-eth0 was written out, and that worked for me.  The fix applied was to start NM before the activated ifcfg-eth0 is written out.  Presumably it kicks NM to re-read the file?  Perhaps that isn't working right?
Comment 4 Orion Poplawski 2008-10-13 11:29:27 EDT
Looks like get_connection() in loader/net.c simply queries NM for status?  If you are starting NM before an interface is activated in the ifcfg-eth? file, seems like you want to send it a message to actually bring up the interface.  In that case it also is no longer necessary to actually re-write the ifcfg-eth? file.  You want to behave more like nm-applet does.
Comment 5 Dan Williams 2008-10-13 15:04:50 EDT
clumens and I looked at it friday and something was writing out the files twice, causing NM to re-read the connection, but the second time the connection was half-written...
Comment 6 Orion Poplawski 2008-10-13 15:22:38 EDT
Don't know if this should have been in today's rawhide, but it's still broken for me.
Comment 7 Orion Poplawski 2008-10-16 10:49:32 EDT
Huzzah, works with 11.4.1.49!

There still seem to be some oddities/duplication in the logs, but perhaps that's normal when you have to bring the network up early to get the kickstart file.

Initial:

08:22:31 INFO    : getting kickstart file
08:22:31 INFO    : only have one network device: eth0
08:22:31 INFO    : doing kickstart... setting it up
08:22:31 DEBUG   : configuring device eth0
08:22:40 DEBUG   : get_connection (1949): NetworkManager connected
08:22:40 INFO    : doing kickstart... setting it up
08:22:40 DEBUG   : configuring device eth0
08:22:40 DEBUG   : get_connection (1949): NetworkManager connected
08:22:40 INFO    : url is saga:/export/data1/ks/rawhide-desk.cfg
08:22:40 DEBUG   : getHostandPath host: |saga:|
08:22:40 DEBUG   : getHostandPath file(1): |/export/data1/ks/rawhide-desk.cfg|
08:22:40 INFO    : file location: nfs:saga:/export/data1/ks/rawhide-desk.cfg
08:22:40 INFO    : setting up kickstart
08:22:40 INFO    : kickstartFromUrl
08:22:40 INFO    : results of url ks, url http://fedora.cora.nwra.com/fedora/linux/development/i386/os

Later:

08:23:27 INFO    : need to set up networking
08:23:27 INFO    : going to pick interface
08:23:27 INFO    : going to do getNetConfig
08:23:27 INFO    : doing kickstart... setting it up
08:23:27 DEBUG   : configuring device eth0
08:23:27 DEBUG   : get_connection (1949): NetworkManager connected

Also, here is what NM was doing.  Still a possibility of a race?

<29>Oct 16 08:22:30 NetworkManager: <info>  starting...
<29>Oct 16 08:22:30 NetworkManager: <info>  Waiting for HAL to start...
<28>Oct 16 08:22:30 NetworkManager: <WARN>  nm_generic_enable_loopback(): error -17 returned from rtnl_addr_add():                       
Sucess  
<29>Oct 16 08:22:30 NetworkManager: <info>  Trying to start the supplicant...
<29>Oct 16 08:22:30 NetworkManager: <info>  Trying to start the system settings daemon...
<28>Oct 16 08:22:30 nm-system-settings: initial_add_devices_of_type: could not get device from HAL: The name org.freedesktop.Hal was not provided by any .service files (2).            
<28>Oct 16 08:22:30 nm-system-settings: initial_add_devices_of_type: could not get device from HAL: The name org.freedesktop.Hal was not provided by any .service files (2).            
<28>Oct 16 08:22:30 nm-system-settings: initial_add_devices_of_type: could not get device from HAL: The name org.freedesktop.Hal was not provided by any .service files (2).            
<28>Oct 16 08:22:30 nm-system-settings:    ifcfg-fedora: Could not get hostname: failed to read /etc/sysconfig/network       
<29>Oct 16 08:22:30 nm-system-settings: Loaded plugin ifcfg-fedora: (c) 2007 - 2008 Red Hat, Inc.  To report bugs please use the NetworkManager mailing list. 
<29>Oct 16 08:22:30 nm-system-settings:    ifcfg-fedora: parsing /etc/sysconfig/network-scripts/ifcfg-eth0 ...      
<29>Oct 16 08:22:30 nm-system-settings:    ifcfg-fedora:     read connection 'System eth0'  
<29>Oct 16 08:22:30 nm-system-settings:    ifcfg-fedora: Ignoring connection 'System eth0' and its device because NM_CONTROLLED was false.                
<29>Oct 16 08:22:30 NetworkManager: <info>  HAL re-appeared     
<29>Oct 16 08:22:30 NetworkManager: <info>  eth0: driver is 'e100'.
<29>Oct 16 08:22:31 NetworkManager: <info>  Found new Ethernet device 'eth0'.
<29>Oct 16 08:22:31 NetworkManager: <info>  (eth0): exported as /org/freedesktop/Hal/devices/net_00_19_d1_04_01_2d                             
<29>Oct 16 08:22:32 nm-system-settings:    ifcfg-fedora: updating /etc/sysconfig/network-scripts/ifcfg-eth0                                                     
<29>Oct 16 08:22:32 nm-system-settings:    ifcfg-fedora: Managing connection 'System eth0' and its device because NM_CONTROLLED was true.              
<27>Oct 16 08:22:32 NetworkManager: connection_updated_cb: assertion `old_connection != NULL' failed                              
<29>Oct 16 08:22:35 NetworkManager: <info>  (eth0): device state change: 1 -> 2
<29>Oct 16 08:22:35 NetworkManager: <info>  (eth0): bringing up device.
<6>e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex


Some other possible issues:

<28>Oct 16 08:22:40 NetworkManager: <WARN>  nm_system_replace_default_ip4_route(): replace_default_ip4_route() returned error Success (0)

Looks like it can't set the hostname (hostname on VT2 returns "localhost.localdomain" instead of "test"):

<29>Oct 16 08:22:40 NetworkManager: <info>  Setting system hostname to 'test' (from DHCP)
<28>Oct 16 08:22:40 NetworkManager: <WARN>  update_etc_hosts(): update_etc_hosts: couldn't read /etc/hosts: (4) Failed to open file '/etc/hosts': No such file or directory        
<28>Oct 16 08:22:40 NetworkManager: <WARN>  update_etc_hosts(): update_etc_hosts: couldn't update /etc/hosts: (4) Failed to open file '/etc/hosts': No such file or directory
<29>Oct 16 08:22:40 NetworkManager: <info>  Setting system hostname to 'localhost.localdomain' (error updating /etc/hosts)     

No idea here:

<28>Oct 16 08:22:40 nm-dispatcher.action: nm_dispatcher_action: Invalid connection: '(null)' / 'connection setting not found' invalid: 1
Comment 8 David Cantrell 2008-10-16 18:12:12 EDT
(In reply to comment #7)
> Huzzah, works with 11.4.1.49!

Thanks.  Marking as CLOSED RAWHIDE.

> There still seem to be some oddities/duplication in the logs, but perhaps
> that's normal when you have to bring the network up early to get the kickstart
> file.
> 
> Initial:
> 
> 08:22:31 INFO    : getting kickstart file
> 08:22:31 INFO    : only have one network device: eth0
> 08:22:31 INFO    : doing kickstart... setting it up
> 08:22:31 DEBUG   : configuring device eth0
> 08:22:40 DEBUG   : get_connection (1949): NetworkManager connected
> 08:22:40 INFO    : doing kickstart... setting it up
> 08:22:40 DEBUG   : configuring device eth0
> 08:22:40 DEBUG   : get_connection (1949): NetworkManager connected
> 08:22:40 INFO    : url is saga:/export/data1/ks/rawhide-desk.cfg
> 08:22:40 DEBUG   : getHostandPath host: |saga:|
> 08:22:40 DEBUG   : getHostandPath file(1): |/export/data1/ks/rawhide-desk.cfg|
> 08:22:40 INFO    : file location: nfs:saga:/export/data1/ks/rawhide-desk.cfg
> 08:22:40 INFO    : setting up kickstart
> 08:22:40 INFO    : kickstartFromUrl
> 08:22:40 INFO    : results of url ks, url
> http://fedora.cora.nwra.com/fedora/linux/development/i386/os
> 
> Later:
> 
> 08:23:27 INFO    : need to set up networking
> 08:23:27 INFO    : going to pick interface
> 08:23:27 INFO    : going to do getNetConfig
> 08:23:27 INFO    : doing kickstart... setting it up
> 08:23:27 DEBUG   : configuring device eth0
> 08:23:27 DEBUG   : get_connection (1949): NetworkManager connected

Yeah, this is all normal.

> Also, here is what NM was doing.  Still a possibility of a race?
[snip]

NetworkManager spews _tons_ of garbage to the console, but still manages to work.  I don't really care about these bugs.  If any of them are cosmetically unpleasing to you, can you file them as bugs against NetworkManager?

Remember also that we are running nm-system-settings during installation as well, which monitors the /etc/sysconfig/network-scripts/ifcfg-* files for changes and then feeds those in to NM.  You're likely to see lots of spew on the terminal.

Thanks.
Comment 9 David Cantrell 2008-10-16 18:14:14 EDT
I meant to say file them as _new_ bugs.

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