Bug 138741 - AMD64 kickstart installs fail finding files
AMD64 kickstart installs fail finding files
Status: CLOSED RAWHIDE
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: anaconda (Show other bugs)
3.0
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Jeremy Katz
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-11-10 17:32 EST by Matthew Riedel
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-04-24 14:03:54 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 Matthew Riedel 2004-11-10 17:32:29 EST
Description of problem:
When using a HTTP kickstart install on X86_64 systems, a possible race
condition prevents anaconda from realizing it has successfully found a
file on th eweb server.

Version-Release number of selected component (if applicable):
RHEL WS 3 U3 

How reproducible:
100%

Steps to Reproduce:
1. Set up a kickstart install that points to a URL for a kickstart file
2. Enter valid IP information (not using DHCP)
3. Anaconda will seem to fail retrieving kickstart file
  
Actual results:
Anaconda reports that it fails to find the kickstart configuration
file, but the web server reports a success code to the query (200):
[log snippet]
<ip_address> - - [10/Nov/2004:15:25:07 -0700] "GET
/cgi-bin/dynamic_ks.cgi?INSTALLMODE=express;LEVEL=ws;VERSION=3;UPDATE=3;ARCH=x86_64
HTTP/1.1" 200 3538 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US;
rv:1.4.3) Gecko/20040924"

Notice the success code in the above log snippet (200).

Expected results:
Should acknowledge successful retrieval, and use the file


Additional info:
Works on i386 fine.  Also fails when the ks.cfg is on the CDROM and
points to a URL installation directory.  Will fail to find
"netstg2.img", even though the server reports a success code.  Also,
in this instance, when anaconda fails back to the user and prompts the
user for hostname/path information, you can leave the default info
(the info it used in the first place), and it will retrieve
netstg2.img fine.
Comment 1 Jeremy Katz 2004-11-10 17:41:48 EST
Which updat erelease is this?  What network adapter and static or dhcp?
Comment 2 Matthew Riedel 2004-11-10 17:49:38 EST
This is RHEL WS3 Update 3.  It is using the tg3 network driver, and
using static IP.  Here is the isolinux.cfg label info for this
particular install:
label ws3x86_64
  kernel vmliws3.x64
  append initrd=initws3.x64 \
ks=http://poopsmith.lanl.gov/cgi-bin/dynamic_ks.cgi?INSTALLMODE=express;LEVEL=ws;VERSION=3;UPDATE=3;ARCH=x86_64

<the append... line is one line, broken up for readability>

Since I'm not sending it any IP info via anaconda, it does a DHCP
broadcase, fails that, and prompts the user for IP information (which
is what I want it to do).  I enter the IP information, and that's when
it fails retrieving the kickstart file (which is dynamically created).


Comment 3 Jeremy Katz 2004-11-10 17:52:44 EST
Could you try the U4 beta and see if it works better?  There are some
changes there explicitly to help with weird link negotiation situations.
Comment 4 Matthew Riedel 2004-11-10 17:55:44 EST
Hmm.. I will give it a shot.  Thanks.
Comment 5 Matthew Riedel 2004-11-12 11:59:51 EST
Seems to be working in RHEL WS 4 Beta 2, thanks!  Is there any chance
of backporting these fixes into the next update for RHEL 3?
Comment 6 Matthew Riedel 2004-11-12 12:00:56 EST
Crap.. misread your request earlier- you wanted me to test the U4
beta, and I tested the RHEL 4 beta... <grumble> I will try again with
the U4 beta, as well.
Comment 7 Jeremy Katz 2004-11-12 13:37:22 EST
U4 beta should have identical changes to RHEL4 beta2, so that's a
promising sign :)
Comment 8 Matthew Riedel 2004-11-12 15:52:17 EST
OK- testing fine with WS3 U4 on X86-64.  I look forward to the
production release- thanks for helping me with this!

Matt
Comment 9 Jeremy Katz 2006-04-24 14:03:54 EDT
Mass-closing lots of old bugs which are in MODIFIED (and thus presumed to be
fixed).  If any of these are still a problem, please reopen or file a new bug
against the release which they're occurring in so they can be properly tracked.

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