mdz at ubuntu.com
Thu Sep 20 00:21:47 BST 2007
On Mon, Sep 17, 2007 at 11:38:31PM +1000, Daniel Pittman wrote:
> Scott James Remnant <scott at ubuntu.com> writes:
> > On Thu, 2007-09-13 at 10:45 -0400, Phillip Susi wrote:
> >> > The difficulty is, the bigger and more complex the server, the
> >> > longer you can normally expect to wait. There are complaints that
> >> > the three minute timeout isn't enough for people's disk arrays on a
> >> > cold morning.
> >> Hence the configurable boot parameter. 3 minutes seems a good
> >> default for "most" configurations. For desktops or servers being
> >> booted up with an admin at the console, being told a drive is still
> >> missing early and given the chance to decide that something is wrong
> >> and that drive WON'T come up so skip it, is handy.
> > The problem is that you don't ever find out that you need the
> > parameter.
> > You boot your server, it boots degraded after three minutes; how do
> > you know that it needed a longer bootdelay? That's a "fail to worst
> > case scenario" solution. Failing to boot at all does have the
> > advantage that you *know* you need to change something.
> Sorry to step in late to this, but would it make sense to replace the
> current fixed timeout with something similar to 'udevsettle' -- ensure
> that all the udev events have been processed before giving up on finding
> the root device?
> That should let you know with confidence that all device discovery has
> finished, even if that takes 45 minutes, and then react to exceptional
> situations such as a degraded RAID array if you have to.
udevsettle, as I understand it, only waits for pending udev events to
complete. It doesn't (and can't) know whether device discovery is complete.
More information about the ubuntu-devel