Unable to get any httprequests: Unable toretreive netstg2.imgfile

John Summerfield debian at herakles.homelinux.org
Sun May 20 00:39:33 UTC 2007


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 at redhat.com
> [mailto:kickstart-list-bounces at redhat.com] 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 at coco.merseine.nu  Z1aaaaaaa at coco.merseine.nu

Please do not reply off-list




More information about the Kickstart-list mailing list