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-06-22 14:54 CEST (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.
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.
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.
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!
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 "||=".
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

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