Re: Unable to get any httprequests: Unable toretreive netstg2.imgfile

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

 



Thanks for bringing the historical perspective to this question, it has indeed been kicked around for years now. But I disagree with the assertion that it's only a Cisco problem. I remember at least two other switch manufacturers involved, including my direct experience with 3com gigabit switches. Also, it hasn't only caused problems for pxe/dhcp installs, but also static ip installs using http and ftp. The only common factors seem to have been gigabit switches/nics, STP, and anaconda.

Wherever the root causes lay, it's a problem during redhat installations, and no other circumstances, that I know about anyway. If it CAN be fixed or worked around in anaconda, then it should be, if only for the sake of RedHat's reputation and their customers' experience. While I don't understand all the issues involved, I do appreciate the recent options intended to help in these situations, and hope your additional suggestions are acted on too.

-Ed


Shabazian, Chip wrote:
While I completely agree that this is something that has been a hassle
and has been the source of more problems than anything I've seen related
to kickstarting systems, we need to keep in mind that these workarounds
are being put into place to deal with a "feature" of the switch.
Wouldn't it be better for Cisco to fix STP so that if it saw a DHCP
packet, it would forward that packet while it determines if it's going
to allow that port on the network?  I can't imagine any loops being
created by forwarding and responding to DHCP packets while ensuring
there are no loops.
We always see this problem on Cisco gear, and in the past 4+ years, I've
only seen this issue as a possibility on one other type of switch (but
the person never responded to the list on whether or not the known Cisco
workarounds helped), yet people think this is an "anaconda" or
"kickstart" problem, not a "Cisco" problem.
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.
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.
Chip


[Index of Archives]     [Red Hat General]     [CentOS Users]     [Fedora Users]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]

  Powered by Linux