Timeout for Ubuntu Server ISO bootsplash
dan.streetman at canonical.com
Tue Nov 28 20:09:50 UTC 2017
On Thu, Nov 23, 2017 at 10:01 AM, Mathieu Trudel-Lapierre
<mathieu.trudel-lapierre at canonical.com> wrote:
> On Thu, Nov 23, 2017 at 4:55 AM, Christian Ehrhardt
> <christian.ehrhardt at canonical.com> wrote:
>> On Thu, Nov 23, 2017 at 1:02 AM, Mathieu Trudel-Lapierre
>> <mathieu.trudel-lapierre at canonical.com> wrote:
>>> I'm revising some of the bootloader logic for the ISO images. Ubuntu Server
>>> currently seems to be one of the things that just wait indefinitely at the
>>> bootloader (grub or isolinux, depending on what/where you are booting).
>>> Is anyone against putting a 5 second timeout in the bootloader, such that
>>> the system carries on to starting the installer automatically?
>> Hi Mathieu,
>> not against the change, but I want to check on a Detail.
>> Is it correct that today it does:
>> A1. boot into bootloader
>> A2. wait forever on users choice
>> And you suggest:
>> B1. boot into bootloader
>> B2. wait 5 sec for users to choose anything special
>> B3. go into the installer (and wait there on the user)
>> If a user can influcence/choose anything in A2 that they can not do
>> anymore in B3 (e.g. special kernel boot options I'd think).
>> Then we should make the timeout on server a bit more than 5 seconds IMHO.
> There is, but it's a matter of setting custom kernel options
> (disabling ACPI, for instance) or adding command-line parameters such
> as for preseeding (which obviously needs to happen before the
> installer starts).
>> The reason I point this out is the (unfortunately usual) combination
>> of slow remote consoles plus 5-10 minute server initialization times.
>> I'm afraid of the admin sitting on a remote server control on a crappy
>> connection for 10 minutes and hitting "oh crap B2 just passed faster
>> than I could see it".
> It's always a possibility, but putting the timeout too high is also
> just waiting for no reason. We should also expect users who preseed or
> install many systems to do so via the network or other means; and the
> idea behind this is to have one common timeout value everywhere rather
> than having many different images behave differently.
>> Not sure what the right value would be, but 30 seconds seem safer to
>> me and it would still eventually reach B3.
> Does it really need to be 30 seconds though? If you're looking for
> things to be more or less automatic, and if you preseed via the initrd
> (which you may do, and we do for automatic testing AFAIK), then you're
> sitting there waiting for 30 seconds when you could have waited for
> much less.
if it's automatic via preseeding, why would anyone be sitting there
waiting for it?
> Remember, any keypress will cancel the timeout, you don't need to have
> done everything within that window.
> On trans-oceanic links, 5 seconds is maybe cutting it a bit short, but
> I wouldn't make it past 15.
IMHO the problem isn't only high RTT (but that certainly makes it much
worse), many times the serial console refresh is very slow (especially
using the IPMI api to the server BMC - which sometimes disconnects
during a reboot but doesn't let you know), so by the time you see the
grub menu starting to draw, it's too late. 15 seconds probably is
enough time if you're staring at the screen ready to press a key
immediately, but if your server takes a few minutes (or worse) to
(re)boot, it gets hard to stare at the screen waiting to press a key
Personally, for a server installer, I think 15 seconds is the minimum,
> Mathieu Trudel-Lapierre <mathieu.trudel-lapierre at canonical.com>
> Freenode: cyphermox, Jabber: mathieu.tl at gmail.com
> 4096R/65B58DA1 818A D123 0992 275B 23C2 CF89 C67B B4D6 65B5 8DA1
> ubuntu-server mailing list
> ubuntu-server at lists.ubuntu.com
> More info: https://wiki.ubuntu.com/ServerTeam
More information about the ubuntu-server