Shabazian, Chip wrote:
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?
Your pruning was a little severe:-(
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.
I think the time for attaching to networks required "in production"
(whatever that means in your circumstances) is after the installation's
done, the configuration is done sufficiently and the system's checked out.
Then, you can worry about what goes where and plug all the right wires
into all the right holes.
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.
I was responding to to someone's point about the cumulative effect of
several long timeouts. By trying all NICs in parallel, there's only one
timeout that matters, and mostly it's fairly short.
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
