Red Hat Bugzilla – Bug 448160
Anaconda kickstart dhcp timeout infinite loop
Last modified: 2008-08-29 15:12:49 EDT
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:
....IPV4 DHCP TIMEOUT...
....IPV4 DHCP TIMEOUT...
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. make boot.iso, without the images/ dir and the kernel params: kssendmac
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
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]
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?
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
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.