Bug 17994

#############################
Update Advisory

grub2-2.02-0.git9752.18.4.mga5 has bee submitted to 5/core/updates_testing


#############################
Description

This update tries to resolve an issue whereby the system may be rendered un-bootable if an attempt is made to install kcm-grub2-0.5.8-12 on UEFI hardware.

############################
Affected Packages
grub2-2.02-0.git9752.18.4.mga5.src.rpm
grub2-2.02-0.git9752.18.4.mga5.i586.rpm
grub2-efi-2.02-0.git9752.18.4.mga5.i586.rpm
grub2-mageia-theme-2.02-0.git9752.18.4.mga5.noarch.rpm
grub2-debuginfo-2.02-0.git9752.18.4.mga5.i586.rpm
grub2-2.02-0.git9752.18.4.mga5.x86_64.rpm
grub2-efi-2.02-0.git9752.18.4.mga5.x86_64.rpm
grub2-debuginfo-2.02-0.git9752.18.4.mga5.x86_64.rpm

###########################
Testing
I don't think this needs testing as I'm not convinced there was a need for it at all, (see my comment #3 in 17918) however having been told twice to do it by Thomas, I have done it.
This will not stop the old kcm-grub2 from uninstalling grub2-efi and installing grub2.

This puzzles me.
"This update tries to resolve an issue whereby the system may be rendered un-bootable if an attempt is made to install kcm-grub2-0.5.8-12 on UEFI hardware.
...
This will not stop the old kcm-grub2 from uninstalling grub2-efi and installing grub2"
The first part seems to indicate that the update will stop the evil if you try to install kcm-grub2 on EFI h/w. The second part says that the evil will happen anyway.

Trying x64 real EFI hardware.
I un-installed kcm-grub2, and updated to:
 grub2-efi-2.02-0.git9752.18.4.mga5
 grub2-mageia-theme-2.02-0.git9752.18.4.mga5

Then tried installing kcm-grub2 from 'issued' repos (the older, not the new one):
 # urpmi kcm-grub2
 [Have to remove the following package]
 grub2-efi-2.02-0.git9752.18.4.mga5.x86_64
 ([because of conflict with grub2]) (y/N) n
I did not dare to go further. This far looks the same as before this grub2 update (but not the kcm-grub2 one 17918).

What *should* one be seeing here? Is it possible that if I had persued the kcm-grub2 installation, it would in fact have been bounced before any damage was done (grub2-efi removed)? If not, what *is* this update supposed to achieve?

CC: (none) => lewyssmith

> If not, what *is* this update supposed to achieve?

I have no idea - ask Thomas.

I repeated several times that I considered that it was not needed but Thomas repeated (irc and qa-ML) that it must be done, so it's done.

See https://bugs.mageia.org/show_bug.cgi?id=17918#c3

Barry

Testing on mga5-64 EFI

Installed from testing:

- grub2-efi-2.02-0.git9752.18.4.mga5.x86_64
- grub2-mageia-theme-2.02-0.git9752.18.4.mga5.noarch

and then

# urpmi --test kcm-grub2
The following package has to be removed for others to be upgraded:
grub2-efi-2.02-0.git9752.18.4.mga5.x86_64


So this update does not avoid the removal of grub2-efi if an attempt is made to install kcm-grub2 < 0.5.8-12.1

This update seems to be redundant since once kcm-grub2-0.5.8-12.1 has been pushed to updates the problem will have been solved

I agree Jim, but Thomas was adamant that it was needed.
https://ml.mageia.org/l/arc/qa-discuss/2016-03/msg00132.html

I've added the OK for mga5-64 since the update is benign, but I don't understand why it's needed.

Whiteboard: (none) => MGA5-64-OK

I understand it's confusing... in this case it's a very "subtle problem"

Conflicts are also used as "install ordering hints"... 

It this case with the conflicts in place when installer or urpmi/rpmdrake gets a request to install grub2-efi, the conflict will tell it to check "is kcm-grub2 installed? if so, ensure the fixed (or newer) one gets installed in the same transaction" in order to avoid possible dep loops...

So just install and confirm grub2(-efi) still works.

And this should really be pushed as part of 17918, not as a separate update

CC: (none) => tmb
Blocks: (none) => 17918

Thanks for the explanation. The issue is obviously a bit more complicated than I had thought. 

I did not mention explicitly, but the system did reboot normally after installing this update.

mga5-32 also boots successfully using the updated grub2 and so I've validated the update.

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs
Whiteboard: MGA5-64-OK => MGA5-64-OK MGA5-32-OK

The advisory in comment#1 should be amended in light of comment#7 and then uploaded to SVN

I've removed my OK's and the validation for this update.

Somewhere in the testing of the grub2 updates I lost the bootloader entries for all but one OS. (I have 6 on this box.)

The problem is almost certainly due to my error, but I'm uncomfortable validating this update until I've sorted things out and re-tested.

Keywords: validated_update => (none)
Whiteboard: MGA5-64-OK MGA5-32-OK => (none)

The loss of bootloader entries was caused by a change in /etc/default/grub
GRUB_DISABLE_OS_PROBER=false had been changed to true

I have twice repeated my tests of of this update as well as kcm-grub2 and os-prober and have been unable to reproduce this change. Perhaps I had at some point inadvertently unchecked the option to "Probe for operating systems" in kcm-grub2.

I have restored my OK's for this update and re-validated.

The advisory in comment#1 needs to be amended in light of comment#7 and then uploaded to SVN

Keywords: (none) => validated_update
Whiteboard: (none) => MGA5-32-OK MGA5-64-OK

An update for this issue has been pushed to the Mageia Updates repository.

http://advisories.mageia.org/MGAA-2016-0050.html

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