grub-reboot changes boot default permanently on Lucid LTS

[Mike C. Delorme]

[Impact]
The grub-reboot manpage says it will "Set the default boot menu entry for GRUB, for the next boot only." But, that's a promise it cannot keep when GRUB cannot write to the environment block, such as when it is stored on Linux software RAID (md) or LVM devices. An administrator of such a system may expect grub-reboot to work as documented, only to find that their change is now permanent, requiring manual recovery. Users without console access may rely on grub-reboot to provide a mechanism for testing a possible-broken boot entry. If that entry causes the system to fail to boot, they may find their system unrecoverable.

[Test Case]
Run grub-reboot on an impacted system and check for a warning and instructions on manually restoring the default. Also, check for a warning in the grub-reboot manpage.

[Regression Risk]
This is a documentation change only. The documentation is emitted by (trivial) code, so a bug in that code could lead to unintentional functional changes.

[Mike C. Delorme (mdelorme)]

It appears that this bug may not actually be related to bug #497326 as per the recent update in that thread. Perhaps this has more to do with the disk configuration that's being used?

[Colin Watson (cjwatson)]

Jordan Uggla points out that his fourth patch in http://lists.gnu.org/archive/html/grub-devel/2009-12/msg00276.html addresses part of this, by at least making grub-reboot not do anything rather than acting like grub-set-default; I'll think about that patch some more but it seems reasonable. Making grub-reboot raise an error immediately is harder but possible. Actually supporting your configuration for grub-reboot is hard and may not ever happen, as it requires writing to the RAID array and GRUB deliberately doesn't implement that right now due to safety concerns.

[Keith Brown (keith-geoffreybrown)]

Regarding the problem of grub-reboot not working with /boot on a RAID array (and in my case not being able to boot back into Ubuntu), I would be happy with a timed default. It wouldn't require GRUB_DEFAULT=saved or grubenv. As I imagine it, a user who normally uses e.g. GRUB_DEFAULT=0 would edit /etc/default/grub to add something like:

GRUB_TIMED_DEFAULT=6 300 # set the default menu entry to 6 for 300 seconds from when grub.cfg is generated

Then the user would run grub-update and it would result in something like the following in grub.cfg (using bash command substitution to get the date but perhaps a special environment variable could be added):

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  load_env
fi
set default="0"
if [ $(date +%s) -le 1319894091 ] ; then # grub-update at Sat Oct 29 15:09:51 CEST 2011; date is 300 seconds in future
  set default="6"
fi
if [ ${prev_saved_entry} ]; then
...

If the user reboots at any point in time in the next 300 seconds then the default menu entry would be 6, after that it would be 0. To guard against a user forgetting that a timed default setting is present grub-update could issue an "are you sure" prompt.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Alesso (alesso)]

The bug is actual still for 12.04 LTS on mirror RAID devices

[Alin Andrei (nilarimogard)]

It still occurs in Raring with no RAID, just a SSD and a HDD.

[Launchpad Janitor (janitor)]

This bug was fixed in the package grub2 - 2.02+dfsg1-5ubuntu4

---------------
grub2 (2.02+dfsg1-5ubuntu4) cosmic; urgency=medium

  * debian/patches/linuxefi_fix_relocate_coff.patch: fix typo in
    relocate_coff() causing issues with relocation of code in chainload.
    (LP: #1792575)

 -- Mathieu Trudel-Lapierre <email address hidden> Mon, 17 Sep 2018 07:45:49 -0400

[Steve Langasek (vorlon)]

Hello Mike, or anyone else affected,

Accepted grub2 into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/grub2/2.02-2ubuntu8.5 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Steve Langasek (vorlon)]

Hello Mike, or anyone else affected,

Accepted grub2-signed into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/grub2-signed/1.93.6 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[dann frazier (dannf)]

Verification:

On a system w/ /boot on an md device:

dannf@mdraid:~$ sudo grub-reboot 0
[sudo] password for dannf:

WARNING: Detected GRUB environment block on diskfilter device
0 will remain the default boot entry until manually cleared with:
    grub-editenv /boot/grub/grubenv unset next_entry

On a system w/ /boot on a /dev/vda:
ubuntu@ubuntu:~$ sudo grub-reboot 2
ubuntu@ubuntu:~$

And it worked as expected.

[Brian Murray (brian-murray)]

Hello Mike, or anyone else affected,

Accepted grub2 into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/grub2/2.02-2ubuntu8.6 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Brian Murray (brian-murray)]

Hello Mike, or anyone else affected,

Accepted grub2-signed into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/grub2-signed/1.93.7 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Mathieu Trudel-Lapierre (cyphermox)]

Verification was done earlier by dannf; this is the same SRU with more patches included for a different issue.

[Mathieu Trudel-Lapierre (cyphermox)]

@dannf, can you please confirm which version of grub you were using for the tests?

[dann frazier (dannf)]

Retested with 2.02-2ubuntu8.6:

dannf@mdraid:~$ sudo grub-reboot 0

WARNING: Detected GRUB environment block on diskfilter device
0 will remain the default boot entry until manually cleared with:
    grub-editenv /boot/grub/grubenv unset next_entry

[Łukasz Zemczak (sil2100)]

The verification of the Stable Release Update for grub2 has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Launchpad Janitor (janitor)]

This bug was fixed in the package grub2-signed - 1.93.7

---------------
grub2-signed (1.93.7) bionic; urgency=medium

  * Rebuild against grub2 2.02-2ubuntu8.6 (LP: #1792575)

grub2-signed (1.93.6) bionic; urgency=medium

  * Rebuild against grub2 2.02-2ubuntu8.5 (LP: #788298)

 -- Mathieu Trudel-Lapierre <email address hidden> Thu, 27 Sep 2018 13:07:26 -0400

[Launchpad Janitor (janitor)]

This bug was fixed in the package grub2 - 2.02-2ubuntu8.6

---------------
grub2 (2.02-2ubuntu8.6) bionic; urgency=medium

  * debian/patches/linuxefi_fix_relocate_coff.patch: fix typo in
    relocate_coff() causing issues with relocation of code in chainload.
    (LP: #1792575)
  * debian/patches/linuxefi_truncate_overlong_reloc_section.patch: The Windows
    7 bootloader has inconsistent headers; truncate to the smaller, correct
    size to fix chainloading Windows 7. (LP: #1792575)

grub2 (2.02-2ubuntu8.5) bionic; urgency=medium

  * debian/patches/grub-reboot-warn.patch: Warn when "for the next
    boot only" promise cannot be kept. (LP: #788298)

 -- Mathieu Trudel-Lapierre <email address hidden> Thu, 27 Sep 2018 17:00:43 +0200

[Seb Bonnard (sebma)]

Correct me if I'm wrong, according to [this documentation](https://www.gnu.org/software/grub/manual/grub/html_node/Environment-block.html), on LVM or RAID disk the /boot/grub/grubenv cannot be modified by GRUB, in that case by the `save_env` routine. Only the OS via `grub-reboot`, `grub-editenv` or `grub-set-default` can modify the `/boot/grub/grubenv` file.

Therefore, the `save_env prev_saved_entry` won't work here (on LVM or RAID disk), and the system will not be able to boot on the previously selected entry.

Is that correct ?