Description of problem: In my setup I use a disc similar to the provided boot.iso to bootstrap to anaconda-kickstart. On this disc, I change the isolinux.cfg, and add the following kernel parameters: kssendmac ks=http://fqdn/path/ks.cfg I removed the images/ directory (stage2.img), to shrink the cd, and to make the bootstrapping process *much* faster. my ks.cfg specifies an IP for the system, but to get it, anaconda is smart enough to attempt dhcp, first. Strangely, if it needs to download the stage2.img, it will acquire dhcp again, even though a static address is specified in the ks.cfg. When the installer is running on a subnet that doesn't have dhcp, it will ask the user to enter an IP (after dhcp attempts time out). It will then use that IP to download the ks.cfg. After it does this, it (incorrectly, and ignoring the ks.cfg) will attempt to do dhcp a second time to download the stage2.img. At this time, if there is no dhcp for the second attempt, the installer goes into an infinite loop. On VT3, I can see that it continues asking for dhcp indefinitely: DHCP DISCOVER..... DHCP DISCOVER..... DHCP DISCOVER..... ....IPV4 DHCP TIMEOUT... DHCP DISCOVER..... DHCP DISCOVER..... DHCP DISCOVER..... ....IPV4 DHCP TIMEOUT... ........ Version-Release number of selected component (if applicable): Fedora 9 How reproducible: Always Steps to Reproduce: 1. make boot.iso, without the images/ dir and the kernel params: kssendmac ks=http://fqdn/path/ks.cfg 2. make that kickstart file specify a STATIC ip address 3. run iso on subnet without dhcp 4. upon first dhcp timeout, specify an IPv4 address, uncheck the use IPv6 box 5. wait for it to attempt dhcp again ===stall=== comments: this worked in fedora 7 just fine. And also, why isn't the installer just using the ip address from the first acquire/user input, if it needs to download the stage2.img?
Created attachment 306549 [details] ks.cfg
Actually, you don't need to remove the images/ dir. it always does this no matter what.
I have figured out that this started happening when I changed the "cdrom" to the "url" parameter in the ks.cfg. The static IP in the ks.cfg, and the already assigned IPs are being totally ignored. anaconda is insisting on getting another DHCP address, and is going in an infinite loop trying to do so.
Seems to be effectively the same problem as 374271? https://bugzilla.redhat.com/show_bug.cgi?id=374271
Apparently with any network URL-based install, the loader required the IP address to come from DHCP. Specifying static ips at the boot line using http://docs.fedoraproject.org/install-guide/f9/en_US/ap-admin-options.html#sn-boot-options-installmethod also does not help. The installer still goes looking for a DHCP IP. Per the above issue, this is known but the end is not yet in sight.
> Seems to be effectively the same problem as 374271? One of the problems is similar. But the thing goes in an infinite loop when DHCP fails this second time (no prompts, etc). This didn't happen in Fedora 7.
This should be fixed in F10 due to the very large amount of work David's been putting in on our networking code.