Bug 466340 - NetworkManager failing when ksdevice is specified with MAC address
NetworkManager failing when ksdevice is specified with MAC address
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
10
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
:
: 467427 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-09 15:46 EDT by eric magaoay
Modified: 2014-06-23 08:12 EDT (History)
6 users (show)

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


Attachments (Terms of Use)
tty3 outputs (12.48 KB, image/png)
2008-10-20 16:41 EDT, eric magaoay
no flags Details
tty4 output (18.95 KB, image/png)
2008-10-20 16:42 EDT, eric magaoay
no flags Details
Test program for SIOCGIWRANGE (1.56 KB, text/plain)
2008-10-21 09:03 EDT, Dan Williams
no flags Details

  None (edit)
Description eric magaoay 2008-10-09 15:46:43 EDT
Description of problem:
Using PXE install with kickstart file, the new install process fails while running NetworkManager.

kernel command line:
kernel /fed/dev/x86_64/os/isolinux/vmlinuz
append initrd=/fed/dev/x86_64/os/isolinux/initrd.img ksdevice=00:14:2a:c9:2e:ec ks=http://192.168.5.101/a/ks/fdb4
====
kickstart file(fdb4):
install
url --url http://192.168.5.101/a/fed/dev/x86_64/os/
lang en_US.UTF-8
keyboard us
network --bootproto dhcp --hostname fdb4
rootpw install
timezone  America/New_York
vnc  --password install --host 192.168.5.101 --port 8888
xconfig --resolution=1024x768
user --name=adm4 --uid=500 --password=install
====
 

Version-Release number of selected component (if applicable):
anaconda-11.4.1.44-1.x86_64.rpm
NetworkManager-0.7.0-0.11.svn4022.4.fc10.x86_64.rpm

How reproducible:
persistent

TTY outputs on alt-ctrl-F3:
INFO: anaconda version 11.4.1.44 on x86_64 starting
INFO: 1024128 kB are available
INFO: getting kickstart file
ERROR: failed to start NetworkManager (9)
ERROR: unable to bring up network

TTY outputs on alt-ctrl-F4:
NetworkManager: 
... HAL re-appeared
    eth0: driver is 'via-rhine'
    Found new Ethernet device 'eth0'
    (eth0): exported as /org/freedestop/Hal/devices/net_00_14_2a_c9_2e_ec
    (eth0): device state change: 1 -> 2
    (eth0): bringing up device
    eth0: link up, 100Mbps, full-duplex, lpa 0x41E1
    (eth0): preparing device
    (eth0): deactivating device
    (eth0); carrier now ON (device state 2)
    (eth0): device state change: 2 -> 3      

TTY outputs on alt-ctrl-F1:
sub-window stating "Error downloading kickstart file"
Comment 1 David Cantrell 2008-10-14 23:50:59 EDT
This is fixed and will be included in the next build of anaconda, which will be anaconda-11.4.1.49-1.

Please test when that version appears in the rawhide tree.
Comment 2 eric magaoay 2008-10-20 16:41:52 EDT
Created attachment 320917 [details]
tty3 outputs
Comment 3 eric magaoay 2008-10-20 16:42:30 EDT
Created attachment 320918 [details]
tty4 output
Comment 4 eric magaoay 2008-10-20 16:45:00 EDT
I just tried the latest build (10/20/08) w/ anaconda ver. 11.4.1.50 it is still
failing. 

Here is another sample program running under qemu-kvm:
===
/usr/bin/qemu-kvm -kernel /a/fed/dev/i386/os/isolinux/vmlinuz -initrd
/a/fed/dev/i386/os/isolinux/initrd.img -append "ksdevice=52:54:00:01:18:40
ks=http://192.168.5.101/a/ks/fda0-17740"  -drive file=/a/q/i/fda0,boot=on 
-localtime -usbdevice tablet -vnc :1840 -monitor stdio -net
nic,vlan=7740,macaddr=52:54:00:01:18:40 -net user,vlan=7740,hostname=fda0-17740
-name fda0-17740 -m 512      
===
kickstart file:
=====
install
url --url http://192.168.5.101/a/fed/dev/i386/os/
lang en_US.UTF-8
keyboard us
network --bootproto dhcp --hostname fda0-17740
rootpw install
timezone  America/New_York
vnc  --password install --host 192.168.5.101 --port 17740
xconfig --resolution=1024x768
user --name=adm0 --uid=500 --password=install
=====
From tty3 it seem it get stuck at:
doing kickstart ... setting it up

on tty4 it says:
NetworkManager: <info> (eth0): device state change: 2 -> 3

I have the attached the snapshot pics of tty3 tty4
Comment 5 David Cantrell 2008-10-20 17:01:03 EDT
I think this is now a NetworkManager issue (or a Hal issue) not understanding the KVM network devices.  Reassigning to NetworkManager.

Dan, in the tty4 output, I see errors from nm-system-settings, but I'm not sure if they are important or not.  Particularly, the error about not knowing the device type for eth0.

Since nm-system-settings is reporting eth0, but the MAC address was specified as a boot argument, that to me means that anaconda successfully translated the MAC address to eth0 so it could write out the ifcfg-eth0 file.  nm-system-settings takes over after that to bring up the interface.
Comment 6 Dan Williams 2008-10-21 09:02:48 EDT
It must not be returning EOPNOTSUPP for SIOCGIWRANGE:

	if (ioctl (fd, SIOCGIWRANGE, &wrq) < 0) {
		if (errno == EOPNOTSUPP)
			success = TRUE;
		goto out;
	}

Need to figure out what it is returning there and whitelist it.   Basically we need a way to concretely determine whether the device is wireless or not, and using GIWRANGE is the only way to do so.  Unfortunately, some devices (ipw3945) return things like EBUSY for GIWRANGE while the regulatory daemon shows up, so we can't just check if GIWRANGE returns success, we need to treat some errors as wireless and others as not wireless.

I think ifup/ifdown just check whether the thing is in /proc/net/wireless, but that's deprecated and should no longer be used.

So, can somebody run the attached program on the problematic network interface and lets see what error it returns?
Comment 7 Dan Williams 2008-10-21 09:03:52 EDT
Created attachment 321012 [details]
Test program for SIOCGIWRANGE

shouldn't require any library deps, just 'gcc -o iwrange-test iwrange-test.c'
Comment 8 eric magaoay 2008-10-21 16:32:27 EDT
I'm using 2 wired-LAN cards, each connected to a separate networks with its own DHCP server. Wireless card is off/disconnected right now. 

Under real hardware PXE install, the install would succeed if I remove ksdevice from the kernel commandline and defined only the kickstart file (ks=http://192.168.5.101/a/ks/fdb4). NetworkManager would then find 2 devices and install would prompt for desired device to use then proceed through completion. For some reason, install would not succeed if there is only one LAN card. 

Under KVM, install fails whether ksdevice is defined or not in kernel commandline. It get stuck in the same place as if using hardware PXE install with one LAN card (shown on previous attachment).
Comment 9 eric magaoay 2008-10-21 18:25:51 EDT
Just want to add the install process succeed under KVM if I use "virtio" device instead of "nic". Here is my actual command running qemu-kvm:

===
# start qemu
/usr/bin/qemu-kvm -kernel /a/fed/dev/i386/os/isolinux/vmlinuz -initrd /a/fed/dev/i386/os/isolinux/initrd.img -append "ksdevice=52:54:00:01:18:40 ks=http://192.168.5.101/a/ks/fda0-17740"  -drive file=/a/q/i/fda0,if=virtio,boot=on  -localtime -usbdevice tablet -vnc :1840 -monitor stdio -net nic,vlan=7740,macaddr=52:54:00:01:18:40,model=virtio -net user,vlan=7740,hostname=fda0-17740 -name fda0-17740 -m 512
===

# here is my kickstart file: ks=http://192.168.5.101/a/ks/fda0-17740
install
url --url http://192.168.5.101/a/fed/dev/i386/os/
lang en_US.UTF-8
keyboard us
network --bootproto dhcp --hostname fda0-17740
rootpw install
timezone  America/New_York
vnc  --password install --host 192.168.5.101 --port 17740
user --name=adm0 --uid=500 --password=install
===

# invoking from remote viewer pc(192.168.5.101):
vncviewer -listen 17740

# invoking from local host to view startup process:
vncviewer :7740
Comment 10 Joe Orton 2008-10-28 11:14:23 EDT
Is is not possible to use e.g. the existence of /sys/class/net/$DEV/wireless/ as a test for the wired-ness of a given interface?
Comment 11 Dan Williams 2008-10-30 01:50:38 EDT
Joe: no, because that (and /proc/net/wireless) are going to go away in the future.  I'll fall back to doing what iwconfig does; if the device returns _any_ error from SIOCGIWNAME, it's not wireless.
Comment 12 Dan Williams 2008-10-30 01:53:49 EDT
fixed upstream in svn r4236
Comment 13 Dan Williams 2008-10-30 01:57:18 EDT
*** Bug 467427 has been marked as a duplicate of this bug. ***
Comment 14 Fedora Update System 2008-11-23 17:55:00 EST
NetworkManager-pptp-0.7.0-0.12.svn4326.fc10,NetworkManager-openvpn-0.7.0-16.svn4326.fc10,NetworkManager-vpnc-0.7.0-0.11.svn4326.fc10,NetworkManager-0.7.0-0.12.svn4326.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/NetworkManager-pptp-0.7.0-0.12.svn4326.fc10,NetworkManager-openvpn-0.7.0-16.svn4326.fc10,NetworkManager-vpnc-0.7.0-0.11.svn4326.fc10,NetworkManager-0.7.0-0.12.svn4326.fc10
Comment 15 Fedora Update System 2008-11-23 18:05:30 EST
NetworkManager-0.7.0-0.12.svn4326.fc9,NetworkManager-vpnc-0.7.0-0.11.svn4326.fc9,NetworkManager-openvpn-0.7.0-16.svn4326.fc9,NetworkManager-pptp-0.7.0-0.12.svn4326.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/NetworkManager-0.7.0-0.12.svn4326.fc9,NetworkManager-vpnc-0.7.0-0.11.svn4326.fc9,NetworkManager-openvpn-0.7.0-16.svn4326.fc9,NetworkManager-pptp-0.7.0-0.12.svn4326.fc9
Comment 16 Fedora Update System 2008-11-23 18:07:46 EST
NetworkManager-0.7.0-0.12.svn4326.fc8,NetworkManager-vpnc-0.7.0-0.11.svn4326.fc8,NetworkManager-openvpn-0.7.0-16.svn4326.fc8,NetworkManager-pptp-0.7.0-0.12.svn4326.fc8 has been submitted as an update for Fedora 8.
http://admin.fedoraproject.org/updates/NetworkManager-0.7.0-0.12.svn4326.fc8,NetworkManager-vpnc-0.7.0-0.11.svn4326.fc8,NetworkManager-openvpn-0.7.0-16.svn4326.fc8,NetworkManager-pptp-0.7.0-0.12.svn4326.fc8
Comment 17 Bug Zapper 2008-11-25 22:43:16 EST
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 18 Fedora Update System 2008-11-26 01:15:18 EST
NetworkManager-0.7.0-0.12.svn4326.fc8, NetworkManager-vpnc-0.7.0-0.11.svn4326.fc8, NetworkManager-openvpn-0.7.0-16.svn4326.fc8, NetworkManager-pptp-0.7.0-0.12.svn4326.fc8 has been pushed to the Fedora 8 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing-newkey update NetworkManager NetworkManager-vpnc NetworkManager-openvpn NetworkManager-pptp'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F8/FEDORA-2008-10263
Comment 19 Fedora Update System 2008-11-26 01:19:22 EST
NetworkManager-0.7.0-0.12.svn4326.fc9, NetworkManager-vpnc-0.7.0-0.11.svn4326.fc9, NetworkManager-openvpn-0.7.0-16.svn4326.fc9, NetworkManager-pptp-0.7.0-0.12.svn4326.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing-newkey update NetworkManager NetworkManager-vpnc NetworkManager-openvpn NetworkManager-pptp'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-10321
Comment 20 Fedora Update System 2008-11-26 01:22:42 EST
NetworkManager-pptp-0.7.0-0.12.svn4326.fc10, NetworkManager-openvpn-0.7.0-16.svn4326.fc10, NetworkManager-vpnc-0.7.0-0.11.svn4326.fc10, NetworkManager-0.7.0-0.12.svn4326.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 21 Fedora Update System 2008-12-21 18:37:59 EST
NetworkManager-0.7.0-0.12.svn4326.fc9, NetworkManager-vpnc-0.7.0-0.11.svn4326.fc9, NetworkManager-openvpn-0.7.0-16.svn4326.fc9, NetworkManager-pptp-0.7.0-0.12.svn4326.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 22 Fedora Update System 2008-12-21 18:42:59 EST
NetworkManager-0.7.0-0.12.svn4326.fc8, NetworkManager-vpnc-0.7.0-0.11.svn4326.fc8, NetworkManager-openvpn-0.7.0-16.svn4326.fc8, NetworkManager-pptp-0.7.0-0.12.svn4326.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.

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