[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

RE: RH9 pxeboot doesn't read ks= boot parameter

the original problem is that the box pxe boots but then cant get an ip when kickstart attempts to contact the dhcp server, and you think this is indicative of kickstart not seeing the ksdevice= kernel append?

similar problem happened to me, but the kernel does see the ksdevice append. -- slowing down the system actually makes sense, though i dont see how a few keystrokes would do it.

if you're on a cisco network, make sure that whatever port you're using has portfast enabled. spanning tree causes all sorts of problems when you shut down a port bring it up and request a dhcp address immediately. --for a short period of time (actually upto 30 seconds) spanning tree can shut down the port... your dhcp discover's arent heard by your dhcp server, and since kickstart cant get network connectivity when it wants it, it drops you to an interactive install. see if you can get your networking guys to turn on portfast on that port @ the switch.

-----Original Message-----
From: Henry Bland [mailto:henry geo ucalgary ca]
Sent: Friday, July 18, 2003 4:59 PM
To: kickstart-list redhat com
Subject: Re: RH9 pxeboot doesn't read ks= boot parameter

> My problem is that pxeboot kicks off starts up and hits 
> /sbin/loader...initializes the eth0 and then prompts for Installation 
> Method.  My pxe.cfg is below so it should be just starting right up in 
> kickstart, but it doesn't.  I've tried the ks=http: option but that 
> doesn't work.

I had a similar problem.  I am using very fast CPUs and found that 
loading down the system by quickly toggling between debug windows 
(ALT-F3, ALT-F4) made my system boot successfully (!).  I solved the 
problem by patching the "loader" application, which lives on the ramdisk 
boot image.

My theory of what happens follows.  During boot, the system performs a 
series of PCI probes.  These appear to make the network card reset (I 
see the link status light blink when this happens).  Immediately after 
this probe, loader attempts to access the kickstart file via http.  This 
access consistently fails unless I slow down the system with keyboard 
strokes.  My short-term fix was to have loader attempt to get the ks.cfg 
file multiple times (instead of just once), pausing between each 
attempt.  It always seems to succeed the second time around.  The same 
problem seems to plague NFS access as well.  I'm not sure which 
subsystem is responsible for ensuring that the NIC is ready to transmit 
before attempting a transmission. In any case, something needs a 
permanent fix.

In order to apply these changes one needs to download anaconda source 
RPM, apply some patches to "loader" and rebuild it, mount the redhat 
ramdisk image, replace the loader executable, unmount the ramdisk, 
recompress the ramdisk.  It's all quite a hassle.  I'm happy to supply 
or post my patches.

Specifics to my system: Intel E1000 network driver version 5.0.43-k1 
using Intel 82547EI Gigabit ethernet controller. Redhat 9, PXELINUX boot.

Henry Bland
University of Calgary

Kickstart-list mailing list
Kickstart-list redhat com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]