On Mon, 2009-06-22 at 09:50 +0200, Hannes Reinecke wrote: > David Dillow wrote: > > On Fri, 2009-06-19 at 11:08 -0500, Victor Lowther wrote: > >> Or you can include ethtool and check every half second until a timeout > >> to see if the link is back. > > > > With most switches, you'll get a link back almost immediately, but it > > will be in blocking mode and won't transmit your packets for 20-30 > > seconds. > > <And a huge grin spreads over my face> > Finally. I'm not alone anymore:-) > (I have been fighting the STP issue for years now.) Yep, portfast is your friend if you have any control over your network... > No, no, no. You don't want to add 'just' a sleep here because things > don't work as expected. Certainly not in this case. Certainly we don't want to sleep if there is no reason to... why slow down the boot if the network admin has the switch nicely configured for us? It may just be a matter of letting DHCP retry a sufficiency long time before we look at the results and try to boot. As long as we don't down the link after getting our information, the mount/login to the root device should proceed fairly quickly. If we do down the link, the blocking mode timer starts again and our very quick boot takes at least 40-60 seconds. So, should we give dhclient 45-60 seconds to do its thing, and the admin can use ip= lines to disable interfaces we know aren't going to get a response? -- To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
