<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.2964" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=174364416-17052007><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=174364416-17052007><FONT face=Arial
color=#0000ff size=2>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.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=174364416-17052007><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=174364416-17052007><FONT face=Arial
color=#0000ff size=2>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.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=174364416-17052007><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=174364416-17052007><FONT face=Arial
color=#0000ff size=2>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.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=174364416-17052007><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=174364416-17052007><FONT face=Arial
color=#0000ff size=2>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.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=174364416-17052007><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=174364416-17052007><FONT face=Arial
color=#0000ff size=2>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.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=174364416-17052007><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=174364416-17052007><FONT face=Arial
color=#0000ff size=2>Chip</FONT></SPAN></DIV><BR>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> kickstart-list-bounces@redhat.com
[mailto:kickstart-list-bounces@redhat.com] <B>On Behalf Of
</B>SSTinsley@upsfreight.com<BR><B>Sent:</B> Thursday, May 17, 2007 9:12
AM<BR><B>To:</B> Discussion list about Kickstart<BR><B>Subject:</B> RE: Unable
to get any httprequests: Unable toretreive netstg2.imgfile<BR></FONT><BR></DIV>
<DIV></DIV><BR><BR><FONT size=2><TT>kickstart-list-bounces@redhat.com wrote on
05/17/2007 08:46:19 AM:<BR><BR>> On Thu, 2007-05-17 at 07:20 -0400,
SSTinsley@upsfreight.com wrote:<BR>> > kickstart-list-bounces@redhat.com
wrote on 05/16/2007 08:28:48 PM:<BR>> > > The reason you can get an IP
and PXEboot is because the NIC is up<BR>> > for<BR>> > > more
than 30 seconds, which gives the switch time to negotiate with<BR>> >
the<BR>> > > NIC and turn up the port. When anaconda starts, it
recycles the NIC<BR>> > (to<BR>> > > load the driver). If
you have portfast issues, anaconda will<BR>> > timeout<BR>> > >
before your switch makes the port live.<BR>> > > <BR>> > >
Ananacoda will also recycle the NIC one more time after it gets the<BR>> >
> ks.cfg, but that one never causes portfast timeout issues.<BR>> >
> <BR>> > <BR>> > I here what your saying. I took your suggestion
to the network guys<BR>> > and they confirmed the <BR>> > switch is
configured correctly. So short of calling them liars, I am<BR>> > pretty
much at a <BR>> > standstill and have to go with the ks.cfg on CDROM.
<BR>> <BR>> you may want to add "nicdelay=40 linksleep=30" to you kernel
command<BR>> line.<BR>> <BR>> I didn't see that in any of your posts so
I thought I'd mention it.<BR>>
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189795<BR>> <BR>>
Note: you can add these to your ifcfg-eth0 conf file as well<BR>> # No
portfast, wait 30s<BR>> LINKDELAY=30<BR>> # DISABLE stupid ZeroConf
address<BR>> NOZEROCONF=1<BR>> <BR>> <BR>> I've been on this list
for a long time and been quite mostly but this is<BR>> a long thread and I
thought I would hop in share my thoughts with the<BR>> rest of the Internet
as well :)<BR>> <BR>> I'm not calling your networking team a liar, but in
the same effect, you<BR>> appear to be experiencing an issue where linkdelay
and nicdelay my come<BR>> in handy for you (works for both static and
dhcp)<BR>> <BR>> -- <BR>> - Kevin Landreth - RHCE<BR>> - Sr. Systems
Architect<BR></TT></FONT><BR><BR><FONT size=2><TT>While this may solve the
problem (and I will try it if I have time), I think</TT></FONT> <BR><FONT
size=2><TT>the thread shows that there is an issue. The fact that DHCP works
fine during</TT></FONT> <BR><FONT size=2><TT>the PXE boot and download of the
kernel and fails in Anaconda should be</TT></FONT> <BR><FONT size=2><TT>reason
enough to a fix to be made. Make the DHCP operate consistently during
the</TT></FONT> <BR><FONT size=2><TT>whole process.</TT></FONT> <BR><BR><FONT
size=2><TT>Thanks for your help</TT></FONT>
<DIV>NOTE: THIS DOCUMENT MAY CONTAIN CONFIDENTIAL AND NONPUBLIC INFORMATION. IT
IS INTENDED ONLY FOR THE USE OF THE INDIVIDUAL(S) OR ENTITY(IES) NAMED ABOVE,
AND OTHERS SPECIFICALLY AUTHORIZED TO RECEIVE IT. If you are not the intended
recipient of this document, you are notified that any review, dissemination,
distribution or copying of this communication is prohibited. If you have
received this communication in error, please notify me immediately by return
email, delete the electronic message and destroy any printed copies. Thank you
for your cooperation.<BR></DIV></BODY></HTML>