On Mon, 2009-06-22 at 18:17 +0200, Seewer Philippe wrote: > David Dillow wrote: > > 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? > > What if he hasn't? That's where this part comes in: > > 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. > > DHCP timeout already is 60 seconds. That's dhclient's default if you > don't provide other options. Ok, then we just need to set the udev settle time to 60 seconds in the event of a netroot and avoid downing the link wherever possible. Given that timeout, the only problem cases are static configs and MTU changes on devices that cannot do that while UP'd. > The problem only manifests itself it we have to correct the mtu after dhcp, > which currently set's the interface down and up (paranoia I guess), or if > we do static configuration. > > For dhcp the solution could be easy: Either we ignore the mtu or don't > down/up the interface to set it. We shouldn't ignore the MTU, and we generally have to down/up the interface to set it. Certainly, we should try to set it without downing the interface, and fall back to the down/set/up sequence if that fails. That would avoid further delay when good hardware/drivers allows it. In the event of static config, or needing to down/up, I think it makes sense to try to ping the server for a period of time and see if we are able to communicate, before we try to get our root. You had even suggested something similar some time back with your original network scripts. But that's not a 'sleep 60' just because we may happen be on a network with a long blocking state. Perhaps I misread what we're talking about and we're on the same page. > > 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? > > Disabling interfaces is not needed I think. If you know which interfaces > are used/not used, you just tell dracut which interface(s) to use. All > other interfaces will be ignored. That's what I meant by disabling. -- 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
