Created attachment 9705 [details]
Patch to spec to fix conflcits

This patch shows a working example of the fix

CC: (none) => JMiahMan

(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

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.

(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

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.

Created attachment 9710 [details]
Updated patch to remove hard conflicts and apply previous explained changes

Attachment 9705 is obsolete: 0 => 1

This all looks fine, I will push changes to cauldron soon.

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

(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

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.

(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.

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...

Also we're still stuck at beta2 while RC1, RC2 & final release happened since

Actually I can reproduce this failure, I had disabled %_debugsource_packages in order to test another package

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?

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...

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.

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.

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...)

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.

(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

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.

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?

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

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...

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.

(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.

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.

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

(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...

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

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

We dont support 32bit efi, so no need to test

(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

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...

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

Oops - forgot about Cauldron.  Shall look at that later.

Keywords: validated_update => (none)

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

Right.  validated can go back.

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