[Bug 1443735] Re: recordfail false positive causes headless servers to hang on boot by default

[Ewan]

Something you may wish to consider in relation to this fix:

Proposal 1)
I noticed the bug description already contains the comment "Maybe a future addition to recognizing $recordfail is to have a warning on the boot menu, but that is outside the scope of this report.". I +1 this for some future update.

Proposal 2) - might be deemed to be low enough risk to implement prior to dev/test/release of proposal 1.
Add the line:
GRUB_RECORDFAIL_TIMEOUT=30
to the default /etc/default/grub file

Context:
I arrived here while investigating a hibernate/resume issue with Ubuntu 15.04 on a Acer C710 (parrot) Chromebook.

Although it is possible to make hibernate/resume functional on this
device, the hibernate action seems to cause recordfail to be set. As a
consequence, I see the grub menu & 30 second countdown on resume. (It's
true that prior to this fix I saw the grub menu with no countdown, which
was even more perplexing - so thank you :)

There were no settings in /etc/default/grub that had a value of 30, so it wasn't immediately obvious to me what was happening.
 
Implementing one of these proposals may avert support questions from laptop users, who experience what might seem an unconfigured / unrequested 30 second delay by grub to laptop resume. OTOH: maybe this configuration is such an edge case it is preferable to do nothing at all

In case someone else arrives here on the same journey, I'll link
https://gist.github.com/ewann/b0aeedf57bd6879946c6 for related Acer C710
issues.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to grub2 in Ubuntu.
https://bugs.launchpad.net/bugs/1443735

Title:
  recordfail false positive causes headless servers to hang on boot by
  default

Status in grub2 package in Ubuntu:
  Fix Released
Status in grub2-signed package in Ubuntu:
  Fix Released
Status in grub2 source package in Precise:
  Fix Released
Status in grub2-signed source package in Precise:
  Fix Released
Status in grub2 source package in Trusty:
  Fix Released
Status in grub2-signed source package in Trusty:
  Fix Released
Status in grub2 source package in Utopic:
  Fix Released
Status in grub2-signed source package in Utopic:
  Fix Released
Status in grub2 source package in Vivid:
  Fix Released
Status in grub2-signed source package in Vivid:
  Fix Released
Status in grub2 package in Debian:
  Fix Released

Bug description:
  [Impact]

  On a headless server system, a user who does not have easy access to
  the console may find the system fails to come up after a power cut
  because the boot is blocked on a console menu prompt from grub that
  does not time out.

  [Workaround]

  Set GRUB_RECORDFAIL_TIMEOUT to some positive value (eg. 30) in
  /etc/default/grub and then run "sudo update-grub". However this needs
  to have been done before the problem occurs; when it has occurred, the
  only option a user has is to add a head to a headless system.

  [Development Fix]

  Default for GRUB_RECORDFAIL_TIMEOUT changed from -1 (indefinite wait)
  to 30 (proceed anyway after 30 seconds). Accepted in Debian, synced to
  Ubuntu in Wily; currently held in wily-proposed due to some items in
  the unapproved queue.

  [Stable Fix]

  Same as development fix.

  [Regression Potential]

  This fix changes user-visible behaviour deliberately because the
  previous behaviour led to this bug. Users of non-headless systems (eg.
  desktop) may miss the boot menu and come back to a failed boot or
  something; but if they attempt again, they should see the menu prompt
  for 30 seconds anyway.

  [Test Case]

  Steps to reproduce:

  1. Boot a Vivid system installed from the server installer (not a cloud image).
  2. Kill the power (or VM) while the kernel is initialising but before it has started init.
  3. Power up the system (or start the VM) again.

  Expected behaviour: the system should boot without user intervention.

  Actual behaviour: the system hangs on the grub prompt.

  [Details]

  This was previously raised in bug 669481 but the solution applied then
  was just to add the GRUB_RECORDFAIL_TIMEOUT setting defaulted to -1.
  This allowed users to work around the problem by tuning
  GRUB_RECORDFAIL_TIMEOUT. I'm filing this bug separately as there is
  nothing wrong with the previous fix, but it didn't fix the problem for
  users by default. This bug is about fixing the default so that users
  don't have to discover and work around the issue.

  An IRC discussion (http://irclogs.ubuntu.com/2015/02/27/%23ubuntu-
  devel.html#t13:54) concluded that everyone involved in the discussion
  is happy to change the timeout from infinity to 30s.

  Colin asked for a fix in Debian, so I'll send a patch there and add a
  bug link. I'm also filing the bug here in order to track the fix in
  both Debian and Ubuntu.

  Importance: High because of the impact to users on headless servers -
  from their perspective, this causes a system to fail to boot after an
  appropriately timed double power cut. I'm prompted to do this today
  because it just happened to me on my server, so perhaps it's more
  likely than I originally thought.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1443735/+subscriptions