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.
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
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
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.
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.
Confirming the new behaviour, but I absolutely love it ;-)
CC: (none) => marja11Assignee: bugsquad => zen25000
(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.
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.
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.
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
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
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.
(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, 6sta2CC: (none) => dvgevers
(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 ;-)
(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
@ 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.
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 => bugsquadSource RPM: (none) => drakxtools-17.82-1.mga6.src.rpm
Assignee: bugsquad => mageiatools
*** Bug 21457 has been marked as a duplicate of this bug. ***
CC: (none) => j.alberto.vc
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
(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
Whiteboard: (none) => MGA6TOOKeywords: 5.1, 6sta2 => (none)
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.
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) => FIXEDStatus: NEW => RESOLVED
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=32165