Bug 430551

Summary: Kickstart config via http requires multiple attempts
Product: [Fedora] Fedora Reporter: Gary Thomas <gary>
Component: anacondaAssignee: Chris Lumens <clumens>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: bpeck, jburke, jonstanley, lkundrak, orion
Target Milestone: ---Flags: jonstanley: fedora_requires_release_note?
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-04-03 18:27:39 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 235706, 430962    

Description Gary Thomas 2008-01-28 13:53:15 EST
Description of problem:

Can't load kickstart via HTTP

Version-Release number of selected component (if applicable): (rawhide 2008-01-25)

How reproducible:


Steps to Reproduce:
1. Start install with "ksdevice=eth0 ks=http://www.mlbassoc.com/thinkpad.ks"
Actual results:

Expected results:

Additional info:

This same syntax worked fine with Fedora 8 (I just tested this same
kickstart file using F8)
Comment 1 Chris Lumens 2008-01-28 17:35:24 EST
Do you have multiple network cards in your computer?
Comment 2 Gary Thomas 2008-01-28 18:23:24 EST
No - only one ethernet (I gave ksdevice=eth0 out of habit)

I think the problem is in how the URL is parsed.  The logs show something 
silly like
  trying to mount http://www.mlbassoc.com///tftpboot/thinkpad.ks
Comment 3 Jon Stanley 2008-02-05 01:27:04 EST
I just ran into this as well.  If you keep hitting OK in the 'cannot retrieve
kickstart' it will go back for DHCP again, and the install will proceed
normally,  Every time, the apache access logs show a successful retrieval of the
file: - - [05/Feb/2008:01:05:20 -0500] "GET /config/rawhide.cfg
HTTP/1.0" 200 1102 "-" "anaconda/" - - [05/Feb/2008:01:06:04 -0500] "GET /config/rawhide.cfg
HTTP/1.0" 200 1102 "-" "anaconda/" - - [05/Feb/2008:01:06:40 -0500] "GET /config/rawhide.cfg
HTTP/1.0" 200 1102 "-" "anaconda/" - - [05/Feb/2008:01:06:41 -0500] "GET /config/rawhide.cfg
HTTP/1.0" 200 1102 "-" "anaconda/" - - [05/Feb/2008:01:06:42 -0500] "GET /config/rawhide.cfg
HTTP/1.0" 200 1102 "-" "anaconda/" - - [05/Feb/2008:01:06:43 -0500] "GET /config/rawhide.cfg
HTTP/1.0" 200 1102 "-" "anaconda/" - - [05/Feb/2008:01:06:52 -0500] "GET
/fedora/development/i386/os/images/updates.img HTTP/1.0" 404 325 "-"
"anaconda/" - - [05/Feb/2008:01:06:52 -0500] "GET
/fedora/development/i386/os/images/product.img HTTP/1.0" 404 325 "-"
"anaconda/" - - [05/Feb/2008:01:06:52 -0500] "GET
/fedora/development/i386/os/images/minstg2.img HTTP/1.0" 200 54345728 "-"

The problem is *not* how the URL is parsed - obviously you can use as many
slashes as you'd like in the URL and everything will be fine.

Let me know if there's something more that you need me to do.  Also, I changed
the subject to something a little more sane and descriptive.
Comment 4 Chris Lumens 2008-02-05 10:14:44 EST
*** Bug 431479 has been marked as a duplicate of this bug. ***
Comment 5 petrosyan 2008-02-05 18:09:28 EST
I can reproduce this bug when running Fedora rawhide under QEMU.

An interesting observation: if I pass "clock=pit" command line option to the
kernel, then kickstart config file retrieval always fails. If I don't provide
that option, it only fails occasionally.
Comment 6 Jon Stanley 2008-03-15 19:41:36 EDT
F9Beta for now.
Comment 7 Jon Stanley 2008-03-18 00:47:21 EDT
This is unlikely to make it for beta.  Proposed release note:

When delivering a kickstart configuration file via http, the retrieval of the
file  will fail, saying that the file could not be retrieved.  Hitting the OK
button several times without making modifications will result in the file being
used.  As a workaround, use one of the other supported methods to retrieve
kickstart configurations.
Comment 8 Chris Lumens 2008-03-20 10:40:34 EDT
*** Bug 432719 has been marked as a duplicate of this bug. ***
Comment 9 Chris Lumens 2008-03-20 10:55:39 EDT
I disagree with use of the word "will" in the first sentence.  This should be
changed to "may", as many people here are unable to reproduce this problem. 
Saying "will" sets up everyone's expectation that it is going to fail, whereas
that does not seem to be the case.
Comment 10 Jesse Keating 2008-04-01 17:01:47 EDT
Where do we stand with this bug?  Has it been fixed yet, do we need to retest?
Comment 11 Orion Poplawski 2008-04-01 17:49:09 EDT
Well, it seems to be working for me now - and it always failed for me before.
Comment 12 Jon Stanley 2008-04-01 20:39:45 EDT
Same here.  I'll close this tomorrow if no one has objections