Bug 18783

We could alter  /etc/default/grub  in install_grub2() instead of write_grub2(), thus only altering it when one goes through drakboot for selecting a default image, and not everytime a kernel or memtest86+ is installed/removed

CC: (none) => thierry.vignaud
Assignee: bugsquad => thierry.vignaud
Source RPM: kernel-4.6.2-3.mga6.src.rpm => drakxtools

(In reply to Thierry Vignaud from comment #1)
> We could alter  /etc/default/grub  in install_grub2() instead of
> write_grub2(), 

That confuses me a bit more. users playing with/in /etc/grub.d/* always runs install_grub2 after changes. I have no problem if code checks for GRUB_SAVEDEFAULT=false and does not dink with GRUB_DEFAULT.

We could add a checkbox for enabling to pick the default image, but why would you go though drakboot if not to change that as it's pretty much the major change it enables to do for grub2.

Offhand, I see no reason for additional user interface questions.

Problem showed up for me when I backup current "Production" install into my /hotbu partition. I boot a previous release run my bkup_mgaX script which mounts partitions, runs rsync then runs reboot to bring "Production" back up. Not so with GRUB_DEFAULT going back to 'saved'. :(

commit 7bb01fb038e0a882e755b963110bda381336b748
Author: Thierry Vignaud <thierry.vignaud@...>
Date:   Fri Jun 24 15:49:14 2016 +0200

    do not alter /etc/default/grub on kernel updates
    
    only when running drakboot (mga#18783)
---
 Commit Link:
   http://gitweb.mageia.org/software/drakx/commit/?id=7bb01fb038e0a882e755b963110bda381336b748

Closing then

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

This fix has caused a regression (see bug 18084 comment 10). When drakx11 attempts to add or remove "nokmsboot" from the boot options, it calls bootloader::write_grub2() (indirectly via bootloader::action('write')) to update the grub2.cfg file. But write_grub2() no longer applies the new options.

Status: RESOLVED => REOPENED
CC: (none) => mageia
Resolution: FIXED => (none)

Damn! It looks like you're right as usual.
I'll revert my commit and do a better change

Created attachment 9116 [details]
Revert "do not alter /etc/default/grub on kernel updates"

Created attachment 9117 [details]
better fix for mga#18783

This hasn't been tested (not even perl_checker tested).
I only checked it passed "perl -cw" (I did this from a non mga box)

I will enhance first patch commit in order to explain the regression and documents it thus behaves like lilo/grub1

The first patch (attachment 9116 [details]) is needed to fix the regression (see also bug 21263). The second patch (attachment 9117 [details]) has been superseded by the fix for bug 20596 (which did the same thing using different syntax).

So should attachment 9116 [details] be pushed in git?

Comment on attachment 9117 [details]
better fix for mga#18783

(In reply to Martin Whitaker from comment #12)
> The first patch (attachment 9116 [details]) is needed to fix the regression
> (see also bug 21263). The second patch (attachment 9117 [details]) has been
> superseded by the fix for bug 20596 (which did the same thing using
> different syntax).

Obsoleting the 2nd patch, then.

(In reply to Thierry Vignaud from comment #11)
> This hasn't been tested (not even perl_checker tested).
> I only checked it passed "perl -cw" (I did this from a non mga box)
> 
> I will enhance first patch commit in order to explain the regression and
> documents it thus behaves like lilo/grub1

Will you have time to do that, soon? 

If not: if this bug is another reason, apart from bug #22274, why many users boot very old kernels without being aware they do, then priority and severity of this bug report should be increased. 

====

Has anyone found time to test this patch attachment 9116 [details] ?

CC: (none) => marja11
Attachment 9117 is obsolete: 0 => 1
Attachment 9117 is patch: 1 => 0

(In reply to Marja Van Waes from comment #14)
> Has anyone found time to test this patch attachment 9116 [details] ?

That patch was applied and released in the recent drakxtools update.

Retesting this issue, I find that GRUB_DEFAULT=0 is no longer replaced by GRUB_DEFAULT=saved. However it is removed completely. It turns out this is unexpected (to me) behaviour of the function MDK::Common::setVarsInSh() which is used to write out the revised /etc/default/grub file. That function will not write out any variable whose value is set to 0.