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"
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.
Created attachment 320917 [details] tty3 outputs
Created attachment 320918 [details] tty4 output
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
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.
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?
Created attachment 321012 [details] Test program for SIOCGIWRANGE shouldn't require any library deps, just 'gcc -o iwrange-test iwrange-test.c'
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).
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
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?
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.
fixed upstream in svn r4236
*** Bug 467427 has been marked as a duplicate of this bug. ***
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
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
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
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
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
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
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.
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.
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.