Bug 125728 - anaconda can't find ks.cfg over http on x86_64
anaconda can't find ks.cfg over http on x86_64
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
2
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-06-10 13:43 EDT by Lars Damerow
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-06-14 17:43:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Lars Damerow 2004-06-10 13:43:24 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6)
Gecko/20040207 Firefox/0.8

Description of problem:
When kickstarting an x86_64 machine, and specifying a
ks=http://server/ks.cfg option, anaconda fails when attempting to
transfer the file to an fd. It then goes to the default interactive
install rather than the automatic kickstart I expect.

Checking the Web server's access log shows that the machine did in fact
connect and download ks.cfg file. I verified this with ethereal.

It works as expected, however, when I retrieve the ks.cfg over nfs.
It also works with either protocol when I use the same configuration
on an i686 machine.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. kickstart x86_64 machine with ks=http://server/ks.cfg option
2. wait for anaconda to start installing automatically
3. be sad when the language choice dialog box appears
4. switch to virtual console 3 to see that ks.cfg could not be
   transferred to an fd
    

Expected Results:  anaconda should have happily retrieved the ks.cfg
data and installed
fedora automatically.

Additional info:

Here's the error:

* doing kickstart... setting it up
* ks location: http://server/ks.cfg
* transferring http://server//./ks.cfg to a fd
* failed to retrieve http://mcp///ks.cfg
Comment 1 Lars Damerow 2004-06-10 13:55:41 EDT
I have an update already, regarding something I should have tried earlier.

A direct http request, like http://server/ks.cfg, works. What seems
to cause the problem is using CGI request syntax, like this:

http://server/ks.rhtml?root=sda&data=sdb

We generate dynamic kickstart configurations that way. I know the
problem isn't likely to be in the dynamic output, since I can wget
the same URL into a static file and retrieve that successfully
with anaconda.

Comment 2 Jeremy Katz 2004-06-14 11:28:56 EDT
What are all of the arguments you're passing?  There's a limit to the
length of the kernel command line and you could be exceeding it
(although that seems unlikely).  I know that we do this at least some
as part of our testing framework and don't remember seeing any problems.
Comment 3 Lars Damerow 2004-06-14 11:36:27 EDT
Hi Jeremy,

Here's the entry from my pxe config file:

label fc2-64
  kernel fedora-core/2/x86_64/vmlinuz
  append ks=http://luna/cgi-bin/ks/ks.py?os=fc2&arch=x86_64
initrd=fedora-core/2/x86_64/initrd.img lang= text devfs=nomount
ramdisk_size=8192 acpi=off reiserfs ksdevice=eth0

thanks,
lars
Comment 4 Jeremy Katz 2004-06-14 17:19:54 EDT
Not reproducing this here on my x86_64 test hardware here.  Is there
any chance you can get a dump of the network and see if it's actually
transferring?  If not, I can try to put together an updated initrd.img
that will give more output to figure out what's going on.
Comment 5 Lars Damerow 2004-06-14 17:39:14 EDT
Hmm--it must be something in our environment here, since it's now
working for me. Sorry for the bother, but thanks for checking it out!
Comment 6 Jeremy Katz 2004-06-14 17:43:12 EDT
Okay, if you start seeing problems again, please reopen
Comment 7 Prakash Shroff 2005-04-06 01:28:43 EDT
Hi,

We are facing the same issue, when ks=http.. but when we tried giving
js=floopy and put a floopy with ks.cfg file in the target x86 machine 
then things are working pretty fine. 

Could you please mention about the environment changes, you have done 
to make it work? are you talking about some network setup?

Thanks
Prakash Shroff
Comment 8 Prakash Shroff 2005-04-06 01:29:55 EDT
(In reply to comment #5)
> Hmm--it must be something in our environment here, since it's now
> working for me. Sorry for the bother, but thanks for checking it out!
Hi,

We are facing the same issue, when ks=http.. but when we tried giving
ks=floopy and put a floopy with ks.cfg file in the target x86 machine 
then things are working pretty fine. 

Could you please mention about the environment changes, you have done 
to make it work? are you talking about some network setup?

Thanks
Prakash Shroff

Note You need to log in before you can comment on or make changes to this bug.