> Then it wouldn't matter much what the timeout is, if eth1 comes up and we can get the ks file from it >(Or later, can get the install source) and eth0 is still dithering around, well we're on the way with > eth1 and who cares? This doesn't work in environments such as a DMZ environment where you have to make sure that the one NIC (out of 3, 4, or more) that is on the only subnet that allows this traffic, is the one that is used. Also, this particular problem isn't whether or not you are accessing the right NIC, but the problem that pump times out before portfast turns the port up. It shouldn't matter if you have one or 20 NIC's, they should all have the same portfast problem. Dialog is good though, if we keep discussing the core issue and come up with a good resolution, we can get this incorporated into the process somewhere to make sure the problem is worked around. -----Original Message----- From: kickstart-list-bounces@xxxxxxxxxx [mailto:kickstart-list-bounces@xxxxxxxxxx] On Behalf Of John Summerfield Sent: Thursday, May 17, 2007 3:45 PM To: Discussion list about Kickstart Subject: Re: Unable to get any httprequests: Unable toretreive netstg2.imgfile Shabazian, Chip wrote: > Now, *I* sure would like to see the timeout for pump increased from 30 > seconds to 60 seconds, but that would probably piss off even MORE > people since I'm sure there are a lot more people who get frustrated > waiting 30 seconds for pump to timeout during boot if their dhcp > server is down, or if they have more than one interface and don't know > how to turn off dhcp on the unused interfaces, etc. If my dhcp server's down, I got problems regardless of the timeout. > > I guess the ideal solution would be an option for pump that does > increase the timeout that could be passed from anaconda, or an option > in anaconda such as dhcpretry=X where you could set the system to > retry dhcp X number of times without recycling the NIC and starting > the negotiation dance again. > > But at the end of the day, please keep in mind that these are all work > arounds for the Cisco STP feature, that while valuable, is the actual > root cause. What _I_ would like to see is an attempt to use them all, configure all the network interfaces in parallel. Use the first one that comes up and allows access to the ks files. Then it wouldn't matter much what the timeout is, if eth1 comes up and we can get the ks file from it (Or later, can get the install source) and eth0 is still dithering around, well we're on the way with eth1 and who cares? -- Cheers John -- spambait 1aaaaaaa@xxxxxxxxxxxxxxxx Z1aaaaaaa@xxxxxxxxxxxxxxxx Please do not reply off-list _______________________________________________ Kickstart-list mailing list Kickstart-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/kickstart-list
