Bug 125728 - anaconda can't find ks.cfg over http on x86_64
Summary: anaconda can't find ks.cfg over http on x86_64
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 2
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-06-10 17:43 UTC by Lars Damerow
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-06-14 21:43:12 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Lars Damerow 2004-06-10 17:43:24 UTC
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 17:55:41 UTC
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 15:28:56 UTC
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 15:36:27 UTC
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 21:19:54 UTC
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 21:39:14 UTC
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 21:43:12 UTC
Okay, if you start seeing problems again, please reopen

Comment 7 Prakash Shroff 2005-04-06 05:28:43 UTC
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 05:29:55 UTC
(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.