[Bug 1443735] [NEW] recordfail false positive causes headless servers to hang on boot

Robie Basak 1443735 at bugs.launchpad.net
Tue Apr 14 02:13:01 UTC 2015


Public bug reported:

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.

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.

** Affects: grub2 (Ubuntu)
     Importance: High
         Status: Triaged

** Description changed:

  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.
  
  This was previously raised in bug 669481 but the solution applied then
- was just to add the RECORDFAIL_TIMEOUT setting defaulted to -1. This
- allowed users to work around the problem by tuning 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.
+ 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.

-- 
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

Status in grub2 package in Ubuntu:
  Triaged

Bug description:
  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.

  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



More information about the foundations-bugs mailing list