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
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.
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.
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
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.
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!
Okay, if you start seeing problems again, please reopen
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
(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