Description of problem: kernel install or removal changes user setting in /etc/default/grub from GRUB_DEFAULT=0 to GRUB_DEFAULT=saved Suggest code should create /etc/default/grub.rpmnew or not modify GRUB_DEFAULT if GRUB_SAVEDEFAULT=false Version-Release number of selected component (if applicable): How reproducible: always Steps to Reproduce: 1. Set GRUB_DEFAULT=0 in /etc/default/grub 2. Install a new kernel or remove an old kernel. 3. grep GRUB_DEFAULT /etc/default/grub Note: GRUB_DEFAULT is no longer 0. :(
Blocks: (none) => 416
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.vignaudAssignee: bugsquad => thierry.vignaudSource RPM: kernel-4.6.2-3.mga6.src.rpm => drakxtools
Keywords: (none) => PATCH
(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 => RESOLVEDResolution: (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 => REOPENEDCC: (none) => mageiaResolution: 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
Summary: 6_s1: kernel install or removal changes user setting in /etc/default/grub => kernel install or removal changes user setting in /etc/default/grubWhiteboard: (none) => MGA6TOO
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=18785
CC: (none) => laidlaws
(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.