Bug 448160

Summary: Anaconda kickstart dhcp timeout infinite loop
Product: [Fedora] Fedora Reporter: Josh Lange <jhlange>
Component: anacondaAssignee: Anaconda Maintenance Team <anaconda-maint-list>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: 9   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-08-29 19:12:49 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
ks.cfg none

Description Josh Lange 2008-05-23 20:19:38 UTC 
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?
Comment 1 Josh Lange 2008-05-23 20:19:38 UTC 
Created attachment 306549 [details]
ks.cfg
Comment 2 Josh Lange 2008-05-29 18:35:41 UTC 
Actually, you don't need to remove the images/ dir.

it always does this no matter what.
Comment 3 Josh Lange 2008-05-29 19:36:48 UTC 
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.
Comment 4 Mykel Alvis 2008-06-11 20:00:06 UTC 
Seems to be effectively the same problem as 374271?
https://bugzilla.redhat.com/show_bug.cgi?id=374271
Comment 5 Mykel Alvis 2008-06-11 20:03:35 UTC 
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.
Comment 6 Josh Lange 2008-06-11 22:03:59 UTC 
> 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.
Comment 7 Chris Lumens 2008-08-29 19:12:49 UTC 
This should be fixed in F10 due to the very large amount of work David's been putting in on our networking code.