daniel at rimspace.net
Mon Sep 17 14:38:31 BST 2007
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
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 188 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20070917/3f2eea69/attachment.pgp
More information about the ubuntu-devel