default timeout is too low, impossible to escape in a VM

Bug #628418 reported by Dustin Kirkland 
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ubuntu CD Images
Fix Released
Undecided
Unassigned
grub-installer (Ubuntu)
Fix Released
High
Colin Watson
Maverick
Fix Released
High
Colin Watson

Bug Description

Binary package hint: grub2

I'm trying to boot an Ubuntu server with kvm -m 1024 -smp 2, and it skips past the boot loader to fast to escape and enter the interactive grub menu, even if I'm holding down the <shift> key (before, during, after) running kvm from the command line.

I believe the problematic option is GRUB_HIDDEN_TIMEOUT=0.

This makes it virtually impossible to enter the grub menu in a fast virtualized environment.

Setting GRUB_HIDDEN_TIMEOUT=1 (and perhaps GRUB_TIMEOUT=9) seem to me to be much friendlier values, and allow server and vm users to actually enter the bootloader menu.

Revision history for this message
Dustin Kirkland  (kirkland) wrote :

Thierry, can I get your opinion on this one? Perhaps a papercut?

tags: added: iso-testing
Revision history for this message
Colin Watson (cjwatson) wrote :

For the moment, this is set as sabdfl instructed me to set it. I argued against it at the time.

Maybe we can act differently on server vs. desktop or something.

Revision history for this message
Dustin Kirkland  (kirkland) wrote : Re: [Bug 628418] Re: default timeout is too low, impossible to escape in a VM

On Wed, Sep 1, 2010 at 6:16 PM, Colin Watson <email address hidden> wrote:
> Maybe we can act differently on server vs. desktop or something.

Yeah, this is all I'm asking for. A non-zero default for servers
and/or virtual machine installations.

Note that as a truly nasty work around, if I run kvm with the -no-kvm
option, it slows things down enough that *sometimes* I can actually
get to the boot menu. Obviously, this is no fix...

Revision history for this message
Thierry Carrez (ttx) wrote :

Right, it's set the way it is to avoid losing one precious second in the desktop boot. I'm all for changing it for "servers".

However, as evidenced by a heated discussion at UDS-M, there is no clear definition of a "server" that would magically allow us to switch between the two settings. Did you have anything in mind, Colin ?

Revision history for this message
Soren Hansen (soren) wrote :

I think for the boot loader, this is pretty simple as it's almost invariably installed by the installer, so we can act differently depending on the install media.

Revision history for this message
Thierry Carrez (ttx) wrote :

Differentiate using the installer being used. Makes sense, for that package :)

Revision history for this message
Soren Hansen (soren) wrote :

I have a couple of patches (for debian-cd and grub-installer) that should get this done. The grub-installer one lets us set the delay, the debian-cd one does it by default for installs done from the server CD. They're completely untested (I've never worked out how to quickly and easily test anything that involves the installer, and I can't devote much time to this), but I hope they can at least serve as a starting point.

I'll push them both in a minute.

Revision history for this message
Dustin Kirkland  (kirkland) wrote :

Marking Triaged (since Soren has attached proposed fixes), High (since this is confirmed serious by multiple Server Core Developers), and proposing for Maverick, and milestoning it against GA (hoping that this gets fixed by then). The latter milestone might be removed by a member of the release team upon consideration.

Changed in grub2 (Ubuntu):
status: New → Triaged
importance: Undecided → High
Changed in grub2 (Ubuntu Maverick):
milestone: none → ubuntu-10.10
Revision history for this message
Dustin Kirkland  (kirkland) wrote :

Soren,

As for testing in the installer, here's what I usually do...

 * Build the binary udeb locally
 * Boot a daily ISO in a VM
 * As soon as the Networking is configured, drop to a shell (Alt-F2)
 * anna-install openssh-client
 * Now you should have scp
 * scp <user>@10.0.2.2:/path/to/your/udeb
 * udpkg -i <your udeb>

I think this should work for the grub-installer package.

Revision history for this message
Thierry Carrez (ttx) wrote :

Milestoned bugs must be assigned. tentatively assigning to Colin so that he reviews the proposed patches.

Changed in grub2 (Ubuntu Maverick):
assignee: nobody → Colin Watson (cjwatson)
tags: added: server-mro
Revision history for this message
Colin Watson (cjwatson) wrote :

Soren, this generally looks fine (and was roughly the approach I was going to take before noticing your patches), but could you call the debconf template grub-installer/timeout instead of grub-installer/boot_delay, for consistency with the /etc/default/grub variable name?

In your debian-cd patch, you're missing "string " before "2".

Revision history for this message
Colin Watson (cjwatson) wrote :

Beware that Dustin's testing approach will not work in this case, because the grub-installer patch adds a new template and udpkg -i needs to be in the right context to talk to the running debconf frontend. Furthermore, it's very important to use udpkg --unpack here since otherwise udpkg will run the new postinst on the spot.

This is awkward - you need to insert the udpkg --unpack call into some carefully chosen postinst that's already sourced the debconf confmodule. Don't worry about it in this case, as I'll sort it out.

Colin Watson (cjwatson)
affects: grub2 (Ubuntu Maverick) → grub-installer (Ubuntu Maverick)
Revision history for this message
Colin Watson (cjwatson) wrote :

I'll make the necessary adjustments to Soren's branches.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package grub-installer - 1.55ubuntu2

---------------
grub-installer (1.55ubuntu2) maverick; urgency=low

  [ Soren Hansen ]
  * Add a preseedable grub-installer/timeout template to adjust the initial
    GRUB timeout (LP: #628418).
 -- Colin Watson <email address hidden> Mon, 06 Sep 2010 12:07:05 +0100

Changed in grub-installer (Ubuntu Maverick):
status: Triaged → Fix Released
Revision history for this message
Colin Watson (cjwatson) wrote :

revno: 1600 [merge]
author: Soren Hansen <email address hidden>, Colin Watson <email address hidden>
committer: Colin Watson <email address hidden>
branch nick: debian-cd
timestamp: Mon 2010-09-06 12:47:14 +0100
message:
  Add a two-second GRUB delay for servers.
    ------------------------------------------------------------
    revno: 1599.1.4
    committer: Colin Watson <email address hidden>
    branch nick: server-timeout
    timestamp: Mon 2010-09-06 12:46:28 +0100
    message:
      same changes to amd64/i386-specific server seed variants
    ------------------------------------------------------------
    revno: 1599.1.3
    committer: Colin Watson <email address hidden>
    branch nick: server-timeout
    timestamp: Mon 2010-09-06 12:44:48 +0100
    message:
      grub-installer/boot_delay -> grub-installer/timeout
    ------------------------------------------------------------
    revno: 1599.1.2
    committer: Colin Watson <email address hidden>
    branch nick: server-timeout
    timestamp: Mon 2010-09-06 12:44:22 +0100
    message:
      formatting, and insert missing "string "
    ------------------------------------------------------------
    revno: 1599.1.1 [merge]
    committer: Colin Watson <email address hidden>
    branch nick: server-timeout
    timestamp: Mon 2010-09-06 12:43:41 +0100
    message:
      merge lp:~soren/debian-cd/ubuntu-server-grub-wait
        ------------------------------------------------------------
        revno: 1594.1.1
        fixes bug(s): https://launchpad.net/bugs/628418
        committer: Soren Hansen <email address hidden>
        branch nick: ubuntu
        timestamp: Thu 2010-09-02 10:24:09 +0200
        message:
          Add a two second GRUB delay for servers.

Changed in ubuntu-cdimage:
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.