Bug 125728
Summary: | anaconda can't find ks.cfg over http on x86_64 | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Lars Damerow <lars> |
Component: | anaconda | Assignee: | Jeremy Katz <katzj> |
Status: | CLOSED WORKSFORME | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 2 | CC: | prakash.shroff |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2004-06-14 21:43:12 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: |
Description
Lars Damerow
2004-06-10 17:43:24 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. 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 |