Red Hat Bugzilla – Bug 471812
crash booting with ks, expecting DHCP-provided kickstart config file name
Last modified: 2008-12-18 15:16:28 EST
Description of problem:
I've long been able to install Fedora and variants off a local NFS/DHCP server, by simply booting with 'ks' in the command line. This still worked on 10-Beta, but not any more on 10-Preview (actually, it was with the 2008-11-12 rawhide snapshot that I hit it first, but I duplicated it on 10-Preview as well).
After obtaining an IP address from the DHCP server, anaconda would now crash. It might or might not be related with some messages about 'nul' or '(null)' information displayed by NetworkManager on one of the VTs.
Using a kickstart file from a local hard disk works, but it's not quite as convenient. I didn't try a ks=nfs: option (I was in a hurry to get the machine functional, and little spare time because of a number of previous hardware failures that led to the new machine), but I did verify that the machine was able to NFS-mount the kickstart-containing directory from the server, after obtaining network configuration from the DHCP server in both non-kickstart and hd-kickstart sessions.
Seems this block didn't make it in the rewrite for the NetworkManager integration. Line 383 in loader/nfsinstall.c
Working on a patch.
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:
Booting from the netinst disk with 'ks' fails to bring up the network interface at first, and then, when I retry, it fails for good and crashes with a SIGSEGV. The /sbin/loader backtrace has: __strdup called by getHostPathandLogin called by getHostandPath called by getFileFromNfs called by getKickstartFile called by main. Before shutting the system down, it prints:
nm-dispatcher.action: _nm_object_get_property: Error getting 'Ip4Config' fr /org/freedesktp/Hal/devices/net_<mm_aa_cc...>: Connection was disconnected before a reply was received.
I tried with and without noipv6, to no avail. I don't have a dhcpv6 server, only dhcpv4.
ks=nfs:server:/path/name manages to download the kickstart file after the initial failure, after you select retry, but then it doesn't seem to use the information in the kickstart file to start anaconda (maybe because I passed it askmethod).
Fix will be in anaconda-22.214.171.124-1.