Bug 21811 - Fix conflicts in grub2 package between grub2 and grub2-efi
Summary: Fix conflicts in grub2 package between grub2 and grub2-efi
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 6
Hardware: All Linux
Priority: Normal minor
Target Milestone: ---
Assignee: QA Team
QA Contact:
URL:
Whiteboard: MGA6TOO MGA6-64-OK MGA6-32-OK
Keywords: advisory, validated_update
Depends on:
Blocks:
 
Reported: 2017-10-07 00:41 CEST by Jeremiah Summers
Modified: 2017-12-06 12:43 CET (History)
12 users (show)

See Also:
Source RPM: grub2-2.02-0.git10463.8.mga6, grub2-2.02-0.git10463.9.mga7
CVE:
Status comment:


Attachments
Patch to spec to fix conflcits (911 bytes, patch)
2017-10-07 00:48 CEST, Jeremiah Summers
Details | Diff
Updated patch to remove hard conflicts and apply previous explained changes (1.31 KB, patch)
2017-10-08 00:17 CEST, Jeremiah Summers
Details | Diff

Description Jeremiah Summers 2017-10-07 00:41:41 CEST
Description of problem:
It seems the grub2 and grub2-efi packages conflict. This should not be the case. With both conflicting it makes it hard to create a UEFI and a BIOS based rescue disk with grub2-mkrescue

Version-Release number of selected component (if applicable):
grub2-2.02-0.git10463.8

How reproducible:
Everytime

Steps to Reproduce:
1. Have grub2 installed and try to install grub2-efi

Each sub package takes control of the /usr/lib/grub, this is not the ideal situation and causes conflicts, the sub package named common should have ownership of that particular directory while the packages grub2 and grub-efi that install modules in their perspective folder in /usr/lib/grub should not.
Comment 1 Jeremiah Summers 2017-10-07 00:48:24 CEST
Created attachment 9705 [details]
Patch to spec to fix conflcits

This patch shows a working example of the fix

CC: (none) => JMiahMan

Comment 2 Marja Van Waes 2017-10-07 15:52:08 CEST
(In reply to Jeremiah Summers from comment #0)
> Description of problem:
> It seems the grub2 and grub2-efi packages conflict. This should not be the
> case. With both conflicting it makes it hard to create a UEFI and a BIOS
> based rescue disk with grub2-mkrescue

I think this needs some discussion, not sure whether discussing can be done in this report, or whether it should be done on dev ml.

CC'ing barjac, tv, tmb and martinw

CC: (none) => mageia, marja11, thierry.vignaud, tmb, zen25000

Comment 3 Martin Whitaker 2017-10-07 16:22:16 CEST
It already came up on the dev ML, starting here

  https://ml.mageia.org/l/arc/dev/2017-06/msg00216.html

Now Mageia 6 is released, I see no reason not to remove the conflict - we've got time to fix anything that breaks.
Comment 4 Marja Van Waes 2017-10-07 16:37:58 CEST
(In reply to Martin Whitaker from comment #3)
> It already came up on the dev ML, starting here
> 
>   https://ml.mageia.org/l/arc/dev/2017-06/msg00216.html
> 
> Now Mageia 6 is released, I see no reason not to remove the conflict - we've
> got time to fix anything that breaks.

Thanks, I had missed that thread... I see no objections in it, only tmb's note:

> If you do, you need to verify atleast that you wont break installer /
> drakboot in case it gets hiccups if both are installed at the same time
> (since it might still be depending on them not being installed at the same
> time).
>

So now would indeed be the best time to remove the conflict.

Assigning to our not-registered grub2 maintainer.

Assignee: bugsquad => zen25000
Whiteboard: (none) => MGA6TOO
Version: 6 => Cauldron
Source RPM: grub2-2.02-0.git10463.8.mga6.src.rpm => grub2-2.02-0.git10463.8.mga6, grub2-2.02-0.git10463.9.mga7

Neal Gompa 2017-10-07 23:59:37 CEST

CC: (none) => ngompa13

Comment 5 Jeremiah Summers 2017-10-08 00:02:01 CEST
I just noticed in the patch I moved the dir around but didn't remove the hard Conflicts. I'll update the patch shorty. I would also like to note I have tested this on a uh.. Mageia esq Install, seems to work ok.
Comment 6 Jeremiah Summers 2017-10-08 00:17:58 CEST
Created attachment 9710 [details]
Updated patch to remove hard conflicts and apply previous explained changes

Attachment 9705 is obsolete: 0 => 1

Comment 7 Barry Jackson 2017-10-08 15:04:52 CEST
This all looks fine, I will push changes to cauldron soon.
Comment 8 Barry Jackson 2017-10-10 22:34:33 CEST
Hmm - seems something in the tool chain has broken the build. It does build for Mga6 but not Cauldron.

The BS builds fail early on during chroot preparation.
http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/updates_testing/20171010172449.barjac.duvel.40270/log

Locally in iurt the problem is during debug package generation with hundreds of lines similar to the last few shown here: (same for i586 and x86_64).
I am suspecting maybe recent security updates to binutils/gdb may be to blame.

BFD: /home/baz/rpmbuild/BUILDROOT/grub2-2.02-0.git10463.10.mga7.i386/usr/lib/grub/i386-efi/part_gpt.module: invalid string offset 1852648736 >= 277 for section `'
BFD: /home/baz/rpmbuild/BUILDROOT/grub2-2.02-0.git10463.10.mga7.i386/usr/lib/grub/i386-efi/part_gpt.module: invalid string offset 1714254950 >= 277 for section `'
BFD: /home/baz/rpmbuild/BUILDROOT/grub2-2.02-0.git10463.10.mga7.i386/usr/lib/grub/i386-efi/part_gpt.module: invalid string offset 762012513 >= 277 for section `'
gdb-add-index: No index was created for /home/baz/rpmbuild/BUILDROOT/grub2-2.02-0.git10463.10.mga7.i386/usr/lib/grub/i386-efi/part_gpt.module
gdb-add-index: [Was there no debuginfo? Was there already an index?]
eu-strip: illformed file '/home/baz/rpmbuild/BUILDROOT/grub2-2.02-0.git10463.10.mga7.i386/usr/lib/grub/i386-efi/part_gpt.module'
chmod: cannot access '/home/baz/rpmbuild/BUILDROOT/grub2-2.02-0.git10463.10.mga7.i386/usr/lib/debug/usr/lib/grub/i386-efi/part_gpt.module-2.02-0.git10463.10.mga7.i386.debug': No such file or directory
/usr/lib/rpm/find-debuginfo.sh: line 481: /tmp/find-debuginfo.EGr6nl/res.*: No such file or directory
error: Bad exit status from /home/baz/rpmbuild/tmp/rpm-tmp.cCXfCA (%install)

Full local build logs are here for i586:
http://mtf.no-ip.co.uk/pub/linux/barjac/distrib/cauldron/i586/log/grub2-2.02-0.git10463.10.mga7.src.rpm/

I would appreciate some help with this,

Barry
Comment 9 Thomas Backlund 2017-10-11 09:31:54 CEST
(In reply to Barry Jackson from comment #8)
> Hmm - seems something in the tool chain has broken the build. It does build
> for Mga6 but not Cauldron.
> 
> The BS builds fail early on during chroot preparation.
> http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/updates_testing/
> 20171010172449.barjac.duvel.40270/log
> 

I've removed glibc-2.26 packages from updates_testing until I can fix i586 upgrade that currently fails


> Locally in iurt the problem is during debug package generation with hundreds
> of lines similar to the last few shown here: (same for i586 and x86_64).
> I am suspecting maybe recent security updates to binutils/gdb may be to
> blame.


I've also pushed a new binutils-2.29.1-3 with more upstream fixes to the bs
Comment 10 Barry Jackson 2017-10-11 13:31:23 CEST
Thanks Thomas,

The new binutils has made no difference to the debug package issue locally.


I will re-submit to updates_testing to see if it builds there.
Comment 11 Barry Jackson 2017-10-11 14:20:22 CEST
(In reply to Barry Jackson from comment #10)
> Thanks Thomas,
> 
> The new binutils has made no difference to the debug package issue locally.
> 
> 
> I will re-submit to updates_testing to see if it builds there.

Ignore that, seems tv already pushed a fix to core without mentioning it here.
Comment 12 Thierry Vignaud 2017-10-11 14:41:41 CEST
Yes, grub2 is indeed broken for months b/c of debuginfo:
http://pkgsubmit.mageia.org/autobuild/history.php?package=grub2

eg: http://pkgsubmit.mageia.org/autobuild/cauldron/x86_64/core/2017-09-06/grub2-2.02-0.git10463.9.mga7.src.rpm/build.0.20170913114309.log

I backported a fix from Fedora (modulo 2 lines regarding /usr/src/debug/ that were breaking the build on my machine)

Sadly my fix worked locally but failed on the BS :-(
http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20171010203102.tv.duvel.29769/log/grub2-2.02-0.git10463.11.mga7/build.0.20171010203143.log
"error: Empty %files file /home/iurt/rpmbuild/BUILD/grub-2.02~beta3/debugsourcefiles.list"

At least, it fails later in the process...
What's strange is that it did build smoothly locally...
Comment 13 Thierry Vignaud 2017-10-11 14:42:17 CEST
Also we're still stuck at beta2 while RC1, RC2 & final release happened since
Comment 14 Thierry Vignaud 2017-10-11 15:08:41 CEST
Actually I can reproduce this failure, I had disabled %_debugsource_packages in order to test another package
Comment 15 Barry Jackson 2017-10-30 20:08:51 CET
This bug is now fixed for cauldron, thanks to joequant's build fix.

I am not yet convinced that it would be safe to update Mga6 with this, however there is MGA6TOO on the whiteboard.

It will see much more testing in cauldron than qa have time to do.

Is this really needed in Mga6 or will Mga7 be soon enough?
Comment 16 Neal Gompa 2017-10-30 20:11:31 CET
Barry,

It blocks me from producing universal disk images for the libguestfs guys, as well as completing the integration work for supporting Mageia in KIWI and beginning work on supporting EFI from livecd-tools.

If we don't want these things to work with Mageia 6, then that's fine, but I'd like to be able to support it without replacing packages myself...
Comment 17 Barry Jackson 2017-10-30 23:33:13 CET
I just had a thought.

Would packages in Mga6 Backports be adequate for your needs?

There should be no upgrade issues going forward to Mga7.
Comment 18 Neal Gompa 2017-10-31 00:44:35 CET
If there are no problems with potentially official disk images having backports enabled by default, sure.

I have a feeling that it isn't acceptable to do that, though.
Comment 19 Thomas Backlund 2017-10-31 08:50:08 CET
I think it would be nice to fix in mga6 to after it has had some "run-time" in cauldron ...

I'd suggest the next thing would be to install both grub2 and grub2-efi on a system and try how drakx tools behaves when trying to alter boot options /customizing boot or installing a new kernel and so on...

Then if it still seems to behave, build it for mga6 (also maybe check if there are more grub2 fixes that could/should be pushed at the same time...)

That would then line up nicely with upcoming mga 6.1 isos (not decided yet, but I will suggest it to council as we will switch to 4.14 longterm kernel and so on...)
Comment 20 Neal Gompa 2017-10-31 10:41:22 CET
That works for me. The last time I tried it, drakboot didn't break, but I didn't look too closely at what happens with a hybrid disk image.
Comment 21 Barry Jackson 2017-10-31 10:44:04 CET
(In reply to Thomas Backlund from comment #19)
> I think it would be nice to fix in mga6 to after it has had some "run-time"
> in cauldron ...
> 

OK

> I'd suggest the next thing would be to install both grub2 and grub2-efi on a
> system and try how drakx tools behaves when trying to alter boot options
> /customizing boot or installing a new kernel and so on...
> 

So far so good, I have both installed in Mga6 for some time now and have not seen any regressions, but I will do some more rigorous testing with drakx tools as you suggest.
Of course I can only test from the UEFI perspective, as I no longer have any PC-BIOS systems.

> Then if it still seems to behave, build it for mga6 (also maybe check if
> there are more grub2 fixes that could/should be pushed at the same time...)
> 

I just updated grub2 to 2.02 full release in Cauldron so I will test this in Mga6 as well.

> That would then line up nicely with upcoming mga 6.1 isos (not decided yet,
> but I will suggest it to council as we will switch to 4.14 longterm kernel
> and so on...)

Sounds good
Comment 22 Martin Whitaker 2017-12-01 11:56:04 CET
Is this ready to go into mga6 Barry? I'm currently working on automating the build of Mageia Live ISOs using grub2, and it's a pain not to have both grub2 and grub2-efi available at the same time.
Comment 23 Barry Jackson 2017-12-01 13:28:51 CET
Is this for 6.1 and if so do you think it should get the full release grub2-2.00 or stick with the snapshot already in Mga6?
I have done quite a bit of testing of the latter in Mga6 with the conflicts removed, but not of the latest from Cauldron, as I thought that the update would not be appropriate. WDYT?
Comment 24 Barry Jackson 2017-12-01 13:55:50 CET
Martin,
Sorry - I just double checked what I have in my Mga6 and it is the full release version as in Cauldron, not the snapshot - I must have been testing both at the time.
I have just re-built it in iurt to check that nothing in Mga6 has broken it and it builds fine, so I can push it to 6/core/updates_testing if you think the update will be accepted.

Barry
Comment 25 Martin Whitaker 2017-12-01 14:04:01 CET
Updating from a pre-release snapshot to the final release seems a reasonable thing to do to me. I can't speak for QA though...
Comment 26 Barry Jackson 2017-12-01 14:33:09 CET
I need to go back to bed and get up again.
It's actually grub2-2.02.0-1.mga6 that I have been using in Mga6 for the last month which is currently in Cauldron as I in fact mentioned in #21 so I think we should go for it. It still builds OK in Mga6.
Will push it to 6/core/updates_testing later today.
Comment 27 Martin Whitaker 2017-12-01 15:11:18 CET
(In reply to Barry Jackson from comment #26)
> I need to go back to bed and get up again.
:-)

> Will push it to 6/core/updates_testing later today.
Thanks Barry.
Comment 28 Barry Jackson 2017-12-01 16:16:19 CET
Package grub2-2.02.0-1.mga6 has been submitted to 6/core/updates_testing, this fixes Bug 21811 - (Fix conflicts in grub2 package between grub2 and grub2-efi).
It also updates grub2 to the full 2.02 release rather than using a possibly unstable intermediate snapshot.

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

This update allows both the grub2 and grub2-efi packages to exist in the same installation, which is useful for some development work.
NOTE: It is not recommended for regular users who should leave the version provided at install of Mageia.
This update also provides the full grub2-2.02 release rather than an intermediate snapshot.

Reference
https://bugs.mageia.org/show_bug.cgi?id=21811

#############################
Affected Packages

grub2-2.02.0-1.mga6.x86_64.rpm
grub2-efi-2.02.0-1.mga6.x86_64.rpm
grub2-common-2.02.0-1.mga6.x86_64.rpm
grub2-mageia-theme-2.02.0-1.mga6.noarch.rpm
grub2-debuginfo-2.02.0-1.mga6.x86_64.rpm

grub2-2.02.0-1.mga6.i586.rpm
grub2-efi-2.02.0-1.mga6.i586.rpm
grub2-common-2.02.0-1.mga6.i586.rpm
grub2-debuginfo-2.02.0-1.mga6.i586.rpm

From:
grub2-2.02.0-1.mga6.src.rpm

############################
Testing

Please update to this version and install either grub2 or grub2-efi depending on which is not installed on your system already.
Check for any regressions especially when using drakx tools to manipulate the bootloader setup from drakboot.
Barry Jackson 2017-12-02 14:07:06 CET

Assignee: zen25000 => qa-bugs

Comment 29 Thomas Andrews 2017-12-04 16:50:37 CET
I'm here because this is listed for QA to test in Mageia 6. I have a question about procedure on this, with respect to Mageia 6 only.

All of my systems are MBR, so they do not use grub2-efi. Like most of our users, I am definitely NOT a developer in any way, so there really isn't ever any good reason for me to have both installed at the same time. 

I'm wondering if tests from the "regular" user's standpoint, where he just has one or the other installed, as should happen, would be useful for this update. 

Or, should I simulate a condition where the "regular" user mistakenly installs both, something that could happen I suppose, but shouldn't?

CC: (none) => andrewsfarm

Comment 30 Thomas Backlund 2017-12-04 16:55:21 CET
(In reply to Thomas Andrews from comment #29)
> I'm here because this is listed for QA to test in Mageia 6. I have a
> question about procedure on this, with respect to Mageia 6 only.
> 
> All of my systems are MBR, so they do not use grub2-efi. Like most of our
> users, I am definitely NOT a developer in any way, so there really isn't
> ever any good reason for me to have both installed at the same time. 
> 
> I'm wondering if tests from the "regular" user's standpoint, where he just
> has one or the other installed, as should happen, would be useful for this
> update. 
> 

Yes, the important thing for you to test is that grub2 still keeps working as intended on your system... 

the conflict removal is more of a "special case" for iso/image builders that wants both installed...
Comment 31 Len Lawrence 2017-12-04 18:10:53 CET
Mageia 6 :: x86_64 :: EFI

Updated grub2 and installed grub2-efi
  grub2                          2.02.0       1.mga6        x86_64  
  grub2-common                   2.02.0       1.mga6        x86_64  
  grub2-efi                      2.02.0       1.mga6        x86_64  
  grub2-mageia-theme             2.02.0       1.mga6        noarch  

Installing for x86_64-efi platform.
Installation finished. No error reported.

The following command was needed because I also ran some oustanding core updates including kernel 4.9.56 and this is a multi-boot system.
$ drakboot --boot
That behaved itself.

Rebooted to the Mate desktop.  The grub2 menu looked perfectly OK.

@TJ Leaving the 64-bit OK to you, presuming your test goes well.

CC: (none) => tarazed25

Comment 32 Thomas Andrews 2017-12-04 19:44:05 CET
I tested this in both 32-bit and 64-bit systems, multibooted on the same MBR hardware: AMD Athlon X2 7750, 8GB, nvidia 9800GT video (nvidia340 driver). In both cases I used MCC tools rather than the command line, and following instructions from Comment 30 I only updated the existing grub2.

I did the 32-bit test first, using MCC/Boot to make the 32-bit grub2 the "active" grub2, and rebooting. After updating grub2 I rebooted again, once using "Mageia," and then again using "Advanced." Everything looked and worked as it should.

I then did the same with the 64-bit install, following the same procedure. Once again, everything looked and worked as it should.

I will add the 64-bit OK to the Whiteboard. Leaving the 32-bit OK for someone who can test using 32-bit grub2-efi.

Whiteboard: MGA6TOO => MGA6TOO MGA6-64-OK

Comment 33 Thomas Backlund 2017-12-04 19:48:05 CET
We dont support 32bit efi, so no need to test
Comment 34 Thomas Andrews 2017-12-04 19:56:44 CET
(In reply to Thomas Backlund from comment #33)
> We dont support 32bit efi, so no need to test

And yet 32-bit grub2-efi is on the list of packages to be tested. Go figure.

OK, will add the 32-bit OK, too.

Whiteboard: MGA6TOO MGA6-64-OK => MGA6TOO MGA6-64-OK MGA-32-OK

Comment 35 Thomas Backlund 2017-12-04 20:00:46 CET
Yeah, grub2 supposedly should work with 32bit efi, which is why its built, but no-one have tested and we decided when we added uefi support that officially only support 64bit efi 

Saves us a lot of pain avoiding some of the buggy 32bit efi hw out there...
Comment 36 Len Lawrence 2017-12-04 20:32:56 CET
I guess this can be validated then.

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

Comment 37 Len Lawrence 2017-12-04 20:35:02 CET
Oops - forgot about Cauldron.  Shall look at that later.

Keywords: validated_update => (none)

Comment 38 Ulrich Beckmann 2017-12-04 21:49:19 CET
Tested on 64-bit EFI-System both Mageia 6 and Cauldron.
No regression found in a multi-boot system with encryption, LVM, and btrfs.

Regards,
Ulrich

CC: (none) => bequimao.de

Comment 39 Len Lawrence 2017-12-04 22:12:06 CET
Right.  validated can go back.
Len Lawrence 2017-12-04 22:12:28 CET

Keywords: (none) => validated_update

Dave Hodgins 2017-12-05 19:15:00 CET

Version: Cauldron => 6
CC: (none) => davidwhodgins

Dave Hodgins 2017-12-05 20:53:36 CET

Keywords: (none) => advisory

Comment 40 Mageia Robot 2017-12-06 12:43:55 CET
An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGAA-2017-0122.html

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


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