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.
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 => zen25000Whiteboard: (none) => MGA6TOOVersion: 6 => CauldronSource RPM: grub2-2.02-0.git10463.8.mga6.src.rpm => grub2-2.02-0.git10463.8.mga6, grub2-2.02-0.git10463.9.mga7
CC: (none) => ngompa13
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.
Assignee: zen25000 => qa-bugs
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-bugsKeywords: (none) => validated_updateWhiteboard: 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.
Keywords: (none) => validated_update
Version: Cauldron => 6CC: (none) => davidwhodgins
Keywords: (none) => advisory
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGAA-2017-0122.html
Status: NEW => RESOLVEDResolution: (none) => FIXED