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@xxxxxxxxxxxxxxx] Sent: Friday, July 18, 2003 4:59 PM To: kickstart-list@xxxxxxxxxx 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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/kickstart-list
