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.
Priority: Normal => HighCC: (none) => thierry.vignaudSeverity: major => critical
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.
Increasing to release blocker as this affects the installer and can't be fixed afterwards.
Priority: High => release_blockerSummary: Upgrade Mga5->6 overwrites /etc/default/grub losing custom settings => Installer upgrade of Mga5->6 overwrites /etc/default/grub losing custom settings
(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.
CC: (none) => marja11Assignee: bugsquad => mageiatoolsSource RPM: (none) => drakx-installer-stage2
Whiteboard: (none) => NEEDHELP
Thierry, any idea about this issue?
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.
Barry: in your case, what kind of changes did you notice? A parameter with another value? Some parameters removed?
(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
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
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
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
Thanks Martin - you are a star! I think this can be closed then.
Thx Martin. I though those fields were protected enough
Closing
Status: NEW => RESOLVEDResolution: (none) => FIXED
(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?
(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).
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.
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.
(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.