Bug 18785 - Grub2 default boot option follows Nth option if Nth option was last chosen, even if the list got reshuffled after running grub2-install
Summary: Grub2 default boot option follows Nth option if Nth option was last chosen, e...
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: x86_64 Linux
Priority: Normal major
Target Milestone: ---
Assignee: Mageia tools maintainers
QA Contact:
URL:
Whiteboard: MGA6TOO
Keywords:
: 21457 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-06-24 20:11 CEST by Herman Viaene
Modified: 2023-08-10 00:41 CEST (History)
6 users (show)

See Also:
Source RPM: drakxtools-17.82-1.mga6.src.rpm
CVE:
Status comment:


Attachments

Description Herman Viaene 2016-06-24 20:11:57 CEST
Description of problem:
Laptop with partitions for Win10, Mageia5 and Mageia6. The grub2 menu shows the various options as defined per installation of M6, but as soon as another option than the default is choosen at boot, this one becomes the default option.

Version-Release number of selected component (if applicable):
M6 sta1

How reproducible:
Happened anumbe of times lately and quite consistently.

Steps to Reproduce:
As  happened today
1. Yesterday booted into Win10 (default wasM5 partition),shut down normally
2.First boot today, rub2 menu shows Windows 10 as default, choose M6
3.Go to MCC (thus booted freshley into it), go to MCC startup options and find M6 as default.
Comment 1 Bit Twister 2016-06-24 20:39:32 CEST
http://www.gnu.org/software/grub/manual/grub.html#Simple-configuration suggests that you can disable that feature. I always want to boot the default install and wrote my own custom script to boot my install by label So I append my settings to /etc/default/grub. snippet follows:

$ tail -6 /etc/default/grub
# Appended by /local/bin/default_grub_changes Tue 21 Jun 06:47 2016
GRUB_CMDLINE_LINUX='noresume ipv6.disable=1 audit=0 vga=794'
GRUB_TIMEOUT=5
GRUB_DEFAULT=0
GRUB_SAVEDEFAULT=false
#****************** end /etc/default/grub ***********************

CC: (none) => bittwister2

Comment 2 Charles Edwards 2016-06-24 21:02:51 CEST
Or you could just remove or change the settings in

GRUB_DEFAULT=saved
GRUB_SAVEDEFAULT=true

Those settings will by default boot the same entry as the last boot

to change that   
##GRUB_DEFAULT=saved
##GRUB_SAVEDEFAULT=true
or
GRUB_DEFAULT=0
GRUB_SAVEDEFAULT=false
and run update-grub2

After either change the default used for all boots will be Mageia (position 1)
in the Grub2 menu.

CC: (none) => cae

Comment 3 Herman Viaene 2016-06-25 09:00:32 CEST
Tx guys, I'll try the change in /etc/default/grub.
But this has never happened before, except for this last sta1. I feel this is now (and hasn't been in the past) a correct default setting.
Comment 4 Herman Viaene 2016-06-25 12:07:05 CEST
There are a few problems with the workarounds proposed:
1. If I edit the /etc/default/grub and then change my mind about what the default option has to be, I change that in MCC, but this one overwrites the file completely, so my changes are gone.
2. Contrary to Bit Twister, I do not always want to boot to the default, I want the flexibility, so i did not test his proposal
3. Charles proposal - as stated -  results in always default booting to option 1, in my case that is the M6 partition. But I want one of my M5 partitions to be the default. After some googling, I tested with commenting out only ##GRUB_SAVEDEFAULT=true and leave GRUB_DEFAULT as MCC pleases to do, thus AFTER having choosen the default in MCC.
Nevertheless, this is all rather clumsy for people who are doing lots of multiboots as I do.
Comment 5 Marja Van Waes 2016-06-25 14:01:28 CEST
Confirming the new behaviour, but I absolutely love it ;-)

CC: (none) => marja11
Assignee: bugsquad => zen25000

Comment 6 Bit Twister 2016-06-25 16:54:48 CEST
(In reply to Herman Viaene from comment #4)

> 3. Charles proposal - as stated -  results in always default booting to
> option 1, in my case that is the M6 partition. 
> But I want one of my M5 partitions to be the default.

link in comment 1 suggests you can use a title instead of a number.

> Nevertheless, this is all rather clumsy for people who are doing lots of
> multiboots as I do.

The other options is for you to write a little stand alone script to set desired value(s) in /etc/default/grub then run update-grub2 or put a custom script in /etc/grub.d/ to provide desired default boot selection. Last option does not require you to remember to run the first option anytime there is a change.

It is not hard:
cd /etc/grub.d/
cp 40_custom 10a_my_default
Then copy desired menu entry from /boot/grub2/grub.cfg into 10a_my_default and run grub-update2.
Comment 7 Charles Edwards 2016-06-25 17:47:23 CEST
If you want a pretty and simple way to make these changes.
Install grub-customizer

It a gui and easily allows you to customize your grub2 and it makes changes to
/etc/default/grub using update-grub2.

It makes it very simple to set the default boot entry especially if|when sub-menus
are involved.
Comment 8 Herman Viaene 2016-06-26 08:49:40 CEST
OK to both comments, I'll check these out.
But is this departure from previous behavior considered a new feature or an improvement? Then I do not see what problem it is supposed to solve.
Comment 9 Marja Van Waes 2016-06-26 10:13:27 CEST
Maybe I love the feature a little less, now :-þ

For me, when this behaviour started, my last chosen cauldron was #2 in the list. However, after installing a new kernel, rebooting and noticing I was still running the old kernel, I ran grub2-install.

Then rebooting, the 2nd entry was still the default, but my last used cauldron had become #1 ;-)

Summary: Grub2 default boot option follows last selected option => Grub2 default boot option follows Nth option if Nth option was last chosen, even if the list got reshuffled after running update-grub2

Marja Van Waes 2016-06-26 10:13:44 CEST

Summary: Grub2 default boot option follows Nth option if Nth option was last chosen, even if the list got reshuffled after running update-grub2 => Grub2 default boot option follows Nth option if Nth option was last chosen, even if the list got reshuffled after running grub2-install

Comment 10 Barry Jackson 2016-07-20 17:47:49 CEST
It's really the user's job to set his preferences in /etc/default/grub - that is how grub2 is configured.

However integrating grub2 with drakboot seems to be causing some friction between what some users want and what drakboot tries to automate.

This particular issue is related to:
https://bugs.mageia.org/show_bug.cgi?id=16059
https://bugs.mageia.org/show_bug.cgi?id=18560

I think that defaulting to GRUB_DEFAULT=saved and GRUB_SAVEDEFAULT=true for everyone is perhaps not a good idea.

@marja
You should not need to run grub2-install (hardly ever).
I think what you intended was update-grub2, to re-create the menu, however this takes it's configuration from /etc/default/grub so unless that changed or the system(s) changed then it should not change anything.
Comment 11 Dick Gevers 2016-12-14 20:15:58 CET
(dvg is dropping this and hiding): 

Live install needs consideration here as well: 

When there is no default at install time, then the choice of "Default" made by the Live user should, I think, be offered afterwards, but (s)he actually does not get to see this Default on first reboot !

@triage: please tell if I need to prove this (I have print screens, journalctl.txt etc.) or need to create a new bug report for Live installed grub2.

Keywords: (none) => 5.1, 6sta2
CC: (none) => dvgevers

Comment 12 Marja Van Waes 2016-12-14 22:08:47 CET
(In reply to Dick Gevers from comment #11)
> (dvg is dropping this and hiding): 
> 
> Live install needs consideration here as well: 
> 
> When there is no default at install time, then the choice of "Default" made
> by the Live user should, I think, be offered afterwards, but (s)he actually
> does not get to see this Default on first reboot !

That sounds as if it's not only not the default, but can't even be selected :-/
> 
> @triage: please tell if I need to prove this (I have print screens,
> journalctl.txt etc.) or need to create a new bug report for Live installed
> grub2.

If the preferred default is not even selectable, then, certainly, please create a separate report.

If it is selectable, then it depends: Could you easily see during install that the previously set default was forgotten? If so, then you could file an enhancement request. If not, then it's a normal bug.

And yes, add all the proof to the new report that you have ;-)
Comment 13 Dick Gevers 2016-12-15 02:14:34 CET
(In reply to Marja van Waes from comment #12)

> That sounds as if it's not only not the default, but can't even be selected
> :-/

...

> If the preferred default is not even selectable, then, certainly, please
> create a separate report.

Oh yes one can select what is in the Live installer and make that Default (it seems!)

> If it is selectable, then it depends: Could you easily see during install
> that the previously set default was forgotten? If so, then you could file an
> enhancement request. If not, then it's a normal bug.

That is not an option in Live: there never is a "previous" because Live is only for new installs (after having taken a preview from another installed O/S with the Live disk most likely)
 
> And yes, add all the proof to the new report that you have ;-)

I don't see you describing an obvious need for an extra report.... ;P
Comment 14 Marja Van Waes 2016-12-15 08:51:50 CET
@ Dick

I misread :-(

I assumed you had already configured grub2 in Live mode, before installing, and that you didn't touch the configuration during install. So "previous" was a reference to that imagninary configuration in Live mode :-/

Of course whatever you configure during install should be respected.
Comment 15 Barry Jackson 2017-05-16 13:12:33 CEST
Re-assigning to bug squad as the default is changed by drakxtools and not set to this new behaviour by the grub2 package itself.

Assignee: zen25000 => bugsquad
Source RPM: (none) => drakxtools-17.82-1.mga6.src.rpm

Rémi Verschelde 2017-05-16 13:35:03 CEST

Assignee: bugsquad => mageiatools

Comment 16 Frédéric "LpSolit" Buclin 2017-08-05 22:25:31 CEST
*** Bug 21457 has been marked as a duplicate of this bug. ***

CC: (none) => j.alberto.vc

Comment 17 Doug Laidlaw 2018-06-11 03:15:36 CEST
I am pretty sure I am in the wrong place, and there is a closed bug somewhere I should reopen.  It is similar to Hermann's bug, but different.

I set my /etc/default/grub to make Mageia the default, but any installation of a new kernel adds a line to the file:

DEFAULT=saved.

This was called a "corner case."  When I complained about it in the right place, I was told that the issue had been fixed a long time before.  Presumably, I was supposed to be imagining the whole thing.

Before I go into detail, should I simply start a new report?

CC: (none) => laidlaws

Comment 18 Marja Van Waes 2018-06-11 07:38:51 CEST
(In reply to Doug Laidlaw from comment #17)
> I am pretty sure I am in the wrong place, and there is a closed bug
> somewhere I should reopen.  It is similar to Hermann's bug, but different.
> 
> I set my /etc/default/grub to make Mageia the default, but any installation
> of a new kernel adds a line to the file:
> 
> DEFAULT=saved.
> 

That looks like bug 18783, tv's first fix for it had to be reverted, so the report was reopened.

The last proposed fix, https://bugs.mageia.org/attachment.cgi?id=9116&action=diff still needs to be tested. Also, tv intends to enhance it.

See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=18783

Marja Van Waes 2018-06-11 07:39:09 CEST

Whiteboard: (none) => MGA6TOO
Keywords: 5.1, 6sta2 => (none)

Comment 19 Doug Laidlaw 2018-06-11 08:35:17 CEST
Thanks Marja.  I will add myself to bug 18783.  Setting the file read-only didn't help.  I have created a copy as I want it, and keep putting it back.
Comment 20 Herman Viaene 2019-02-19 17:08:00 CET
Since the EOL of M5, the "conflict" between the old and new behavior in grub(2) is gone. I don't see any use in keeping this bug open.

Resolution: (none) => FIXED
Status: NEW => RESOLVED

katnatek 2023-08-10 00:41:51 CEST

See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=32165


Note You need to log in before you can comment on or make changes to this bug.