Bug 20596 - Installer upgrade of Mga5->6 overwrites /etc/default/grub losing custom settings
Summary: Installer upgrade of Mga5->6 overwrites /etc/default/grub losing custom settings
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: Installer (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: release_blocker critical
Target Milestone: ---
Assignee: Mageia tools maintainers
QA Contact:
URL:
Whiteboard: NEEDHELP
Keywords:
Depends on:
Blocks:
 
Reported: 2017-03-29 18:52 CEST by Barry Jackson
Modified: 2017-11-03 10:00 CET (History)
4 users (show)

See Also:
Source RPM: drakx-installer-stage2
CVE:
Status comment:


Attachments

Description Barry Jackson 2017-03-29 18:52:43 CEST
Description of problem:
/etc/default/grub is edited during upgrade from Mga5 to Cauldron.

This is fork from https://bugs.mageia.org/show_bug.cgi?id=20429 where I attempted to fix this in the packaging of grub2 by various means including saving the file in %pre and copying it back in %triggerpostun common when the Mga5 grub2{,-efi} was removed.

I am now thinking that the issue is caused by the installer after the package is installed such that it can't be fixed in the grub2 packaging.

I will check whether this happens in a urpmi upgrade to confirm that the installer is causing this.

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


How reproducible:


Steps to Reproduce:
1.
2.
3.
Barry Jackson 2017-03-29 18:57:39 CEST

Priority: Normal => High
Severity: major => critical
CC: (none) => thierry.vignaud

Comment 1 Barry Jackson 2017-03-30 01:33:04 CEST
I have confirmed that rpm is NOT misbehaving as a result of the file move from grub2{,-efi} to grub2-common during upgrade, as was suspected back in the original bug report linked above.

A urpmi upgrade works fine using the current cauldron grub2.

/etc/default/grub.rpmnew is created and /etc/default/grub is left untouched.

/etc/default/grub.rpmnew is then (correctly) deleted as per the spec.

The problem ONLY happens when using the installer to do the upgrade.
Comment 2 Barry Jackson 2017-03-30 01:35:20 CEST
Increasing to release blocker as this affects the installer and can't be fixed afterwards.

Priority: High => release_blocker
Summary: Upgrade Mga5->6 overwrites /etc/default/grub losing custom settings => Installer upgrade of Mga5->6 overwrites /etc/default/grub losing custom settings

Comment 3 Marja van Waes 2017-03-30 08:56:52 CEST
(In reply to Barry Jackson from comment #1)
> I have confirmed that rpm is NOT misbehaving as a result of the file move
> from grub2{,-efi} to grub2-common during upgrade, as was suspected back in
> the original bug report linked above.
> 
> A urpmi upgrade works fine using the current cauldron grub2.
> 
> /etc/default/grub.rpmnew is created and /etc/default/grub is left untouched.
> 
> /etc/default/grub.rpmnew is then (correctly) deleted as per the spec.
> 
> The problem ONLY happens when using the installer to do the upgrade.

Assigning to stage2, then.

Assignee: bugsquad => mageiatools
Source RPM: (none) => drakx-installer-stage2
CC: (none) => marja11

Rémi Verschelde 2017-04-04 10:53:47 CEST

Whiteboard: (none) => NEEDHELP

Comment 4 Rémi Verschelde 2017-04-26 13:17:47 CEST
Thierry, any idea about this issue?
Comment 5 Frédéric Buclin 2017-05-15 17:19:54 CEST
I did an upgrade from Mageia 5 to 6 using the Mageia 6 RC DVD from this week-end, and I cannot reproduce the issue. The two custom entries in /et/default/grub I had in Mageia 5 are still there after the upgrade to Mageia 6.
Comment 6 Frédéric Buclin 2017-05-15 17:22:11 CEST
Barry: in your case, what kind of changes did you notice? A parameter with another value? Some parameters removed?
Comment 7 Barry Jackson 2017-05-15 17:30:37 CEST
(In reply to Frédéric Buclin from comment #6)
> Barry: in your case, what kind of changes did you notice? A parameter with
> another value? Some parameters removed?

The details are in the original bug linked in comment 0
Comment 8 Doug Laidlaw 2017-06-17 11:46:53 CEST
HOORAY!  Somebody else has this problem.

I have a multi-boot system.  If I boot into something else, I want to be able to go back to my default OS (currently 6 RC.) So, I have changed the default in /etc/default/grub from "saved" to "0."

On every kernel update, a line GRUB_DEFAULT="Saved" is added to the end of the file.  Because it is seen last, it takes priority over anything I have written higher up.  If I add GRUB_DEFAULT="0" after it, a new GRUB_DEFAULT="Saved" is added after that.

The only way around it I can see is to use rc.local to substitute a backup copy and run update-grub again on every boot, but I shouldn't have to!

CC: (none) => laidlaws

Comment 9 Martin Whitaker 2017-06-21 21:55:48 CEST
Yes, when you use the classic installer to perform an upgrade, it reinstalls the bootloader after you exit the summary screen. I think this is necessary; things may well change from release to release. It's also a useful feature, in that it provides an easy way to reinstall the bootloader for an installed system if you've accidentally damaged it (or installed another system, but then want to go back to your original bootloader).

The code that rewrites /etc/default/grub is bootloader::write_grub2_sysconfig. This attempts to preserve most existing settings, but not comments, which is why Barry's test didn't work. The settings it modifies are:

    $conf{GRUB_CMDLINE_LINUX_DEFAULT} = $bootloader->{default_append} || get_grub2_append($bootloader);
    $conf{GRUB_GFXPAYLOAD_LINUX} = 'auto' if is_uefi();
    $conf{GRUB_DISABLE_RECOVERY} = 'false'; # for 'failsafe' entry
    $conf{GRUB_DEFAULT} ||= 'saved'; # for default entry but do not overwrite user choice
    $conf{GRUB_SAVEDEFAULT} ||= 'true'; # for default entry but do not overwrite user choice
    $conf{GRUB_TIMEOUT} = $bootloader->{timeout};

(the timeout gets read from the existing bootloader config earlier on, so is in fact preserved)

There is a corner-case bug in the above; "||=" will overwrite the existing setting if the value of that setting is zero. I would have said this was the cause of Doug's problem, but bootloader::write_grub2_sysconfig is only called by the installer, and not on every kernel update. I am unable to reproduce Doug's problem; I manually changed the GRUB_DEFAULT setting to 0 and then updated to the latest kernel, and the setting was preserved.

The fix for this corner-case bug is to use "//=" instead of "||=".

CC: (none) => mageia

Comment 10 Mageia Robot 2017-06-22 09:30:52 CEST
commit b6addf45ac88c40ead767bfd8ada635558b108d6
Author: Martin Whitaker <mageia@...>
Date:   Thu Jun 22 08:23:06 2017 +0100

    Don't overwrite custom grub2 settings when updating/upgrading (mga#20596)
    
    Fixes a corner case bug where GRUB_DEFAULT and GRUB_SAVEDEFAULT would be
    overwritten if previously set to a value that evaluates as false.
---
 Commit Link:
   http://gitweb.mageia.org/software/drakx/commit/?id=b6addf45ac88c40ead767bfd8ada635558b108d6
Comment 11 Barry Jackson 2017-06-22 11:16:14 CEST
Thanks Martin - you are a star!

I think this can be closed then.
Comment 12 Thierry Vignaud 2017-06-22 14:04:32 CEST
Thx Martin.
I though those fields were protected enough
Comment 13 Thierry Vignaud 2017-06-22 14:54:59 CEST
Closing

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

Comment 14 Doug Laidlaw 2017-11-02 02:50:33 CET
(In reply to Mageia Robot from comment #10)
> commit b6addf45ac88c40ead767bfd8ada635558b108d6
> Author: Martin Whitaker <mageia@...>
> Date:   Thu Jun 22 08:23:06 2017 +0100
> 
>     Don't overwrite custom grub2 settings when updating/upgrading (mga#20596)
>     
>     Fixes a corner case bug where GRUB_DEFAULT and GRUB_SAVEDEFAULT would be
>     overwritten if previously set to a value that evaluates as false.
> ---
>  Commit Link:
>   
> http://gitweb.mageia.org/software/drakx/commit/
> ?id=b6addf45ac88c40ead767bfd8ada635558b108d6

In fact, the opposite happens now.  The default setting of "saved" is restored, even if there has been no update.  Can I make /etc/default/grub read-only?
Comment 15 Martin Whitaker 2017-11-02 22:26:35 CET
(In reply to Doug Laidlaw from comment #14)
> (In reply to Mageia Robot from comment #10)
> > commit b6addf45ac88c40ead767bfd8ada635558b108d6
> > Author: Martin Whitaker <mageia@...>
> > Date:   Thu Jun 22 08:23:06 2017 +0100
> > 
> >     Don't overwrite custom grub2 settings when updating/upgrading (mga#20596)
> >     
> >     Fixes a corner case bug where GRUB_DEFAULT and GRUB_SAVEDEFAULT would be
> >     overwritten if previously set to a value that evaluates as false.
> > ---
> >  Commit Link:
> >   
> > http://gitweb.mageia.org/software/drakx/commit/
> > ?id=b6addf45ac88c40ead767bfd8ada635558b108d6
> 
> In fact, the opposite happens now.  The default setting of "saved" is
> restored, even if there has been no update.  Can I make /etc/default/grub
> read-only?

What is causing it to be rewritten? I have just tried:

  - installing from a Live DVD
  - modifying /etc/default/grub
  - updating the system

and /etc/default/grub was not touched by the updates.

If you can provide a sequence of operations that will reliably reproduce your bug, I'll take another look. Probably best to open a new bug report for this (and put me on CC).
Comment 16 Doug Laidlaw 2017-11-02 23:22:54 CET
OK.  I am ill and "not quite with it" at present.  There may be something I have missed.  

The last line in my /etc/default/grub is 

GRUB_DEFAULT="0"

Something writes after that

GRUB_DEFAULT="Saved"

It seems to be happening spontaneously, even when there is no update involved.  I have been adding items to my Grub2 menu.  I have saved a "good" copy of the file and usually copy it into place before running update-grub.

The file should be touched only by an update which affects it.  The only one I can think of is a kernel update, but your test would have included that.
Comment 17 Doug Laidlaw 2017-11-02 23:29:22 CET
P.S. I closed too early.  My /etc/default/grub at present shows 

GRUB_DEFAULT="0"
GRUB_DEFAULT="Saved"

The date on the file was Nov 2, and I have just got out of bed on Nov 3, my time.
Comment 18 Martin Whitaker 2017-11-03 10:00:32 CET
(In reply to Doug Laidlaw from comment #16)
> The file should be touched only by an update which affects it.  The only one
> I can think of is a kernel update, but your test would have included that.

Yes, I specifically checked that. The kernel update caused /boot/grub2/grub.cfg to be updated (as expected) but didn't touch /etc/defaults/grub (also as expected).

The only thing I would expect to modify /etc/defaults/grub would be a grub2 package update, but there's not been one yet for Mageia 6.

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