Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 533264 - sys-boot/grub - grub2-reboot sets next_entry but reboot does not clear it
Summary: sys-boot/grub - grub2-reboot sets next_entry but reboot does not clear it
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: AMD64 Linux
: Normal normal (vote)
Assignee: Gentoo's Team for Core System packages
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-12-22 08:04 UTC by Romain Riviere
Modified: 2021-06-20 18:07 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Romain Riviere 2014-12-22 08:04:35 UTC
grub2-reboot sets grubenv's next_entry properly, and the next boot uses that entry, as expected.
However, next_entry is not cleared after the boot, as can be seen in grubenv and verified by subsequent reboots. As a result, grub2-reboot results in a new, permanent default.

Reproducible: Always

Steps to Reproduce:
1. grub2-reboot '0' 
2. reboot

Actual Results:  
System boots on entry 0, but grubenv keeps the next_entry=0 setting

Expected Results:  
next_entry should be cleared by 00_header lines 54-58 (verified present in actual /boot/grub/grub.cfg)

In my /etc/default/grub, GRUB_DEFAULT=1 is the only enabled setting.
I verified that the bug is present on two different machines, both running fresh amd64 installs. I also reproduced the bug with 2.00_p5107-r2, 2.02_beta2-r3 and 2.02_beta2-r6.
My /boot lives on /dev/md1, a 0.90 RAID. grub.fg is set to load mdraid09 accordingly. However, grub2 is installed on /dev/sda and /dev/sdb.
Comment 1 Austin S. Hemmelgarn 2015-12-11 14:01:58 UTC
This is actually intended behavior in GRUB.  You're supposed to set up your grub.cfg to clear the variable.

Try adding something like this to each of the menu entries in your grub.cfg:

if [ "${next_entry}" ] ; then
    set next_entry=
    save_env next_entry
fi
Comment 2 Doug Goldstein (RETIRED) gentoo-dev 2015-12-11 14:14:49 UTC
(In reply to Austin S. Hemmelgarn from comment #1)
> This is actually intended behavior in GRUB.  You're supposed to set up your
> grub.cfg to clear the variable.
> 
> Try adding something like this to each of the menu entries in your grub.cfg:
> 
> if [ "${next_entry}" ] ; then
>     set next_entry=
>     save_env next_entry
> fi

The whole point of the command is to do it once (as interpreted from the man page) and not to make it a permanent setting (grub2-set-default is for that). So I believe this bug report is valid. Your statement that this code needs to be added is also correct and we should likely have that in our default output of grub2-mkconfig.
Comment 3 Mike Gilbert gentoo-dev 2015-12-11 15:19:13 UTC
Send a patch upstream please.
Comment 4 Joe 2018-04-24 09:16:44 UTC
It appears if grub2 has an issue with writing on boot partitions that are on raid/lvm

Source:
https://bugzilla.suse.com/show_bug.cgi?id=865227#c3


Potentially related bug report:
https://savannah.gnu.org/bugs/index.php?44167
Comment 5 Mike Gilbert gentoo-dev 2021-06-20 18:07:20 UTC
00_header in grub-2.06 has this:

if cmostest $GRUB_BUTTON_CMOS_ADDRESS ; then
   set default="${GRUB_DEFAULT_BUTTON}"
elif [ "\${next_entry}" ] ; then
   set default="\${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="${GRUB_DEFAULT}"
fi