Bug 1506704 - Nothing in Fedora 27+ grub2 obsoletes/provides grub2-efi-modules (breaks upgrades)
Summary: Nothing in Fedora 27+ grub2 obsoletes/provides grub2-efi-modules (breaks upgr...
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: grub2
Version: 27
Hardware: x86_64
OS: Linux
high
high
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords: Reopened
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-10-26 15:23 UTC by Jeremy Nickurak
Modified: 2018-04-02 21:17 UTC (History)
31 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2018-02-14 17:26:50 UTC


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Bugzilla 1491624 None CLOSED grub2-tools does not belong to a distupgrade repository, causes software-upgrade failure 2019-04-02 05:14 UTC
Red Hat Bugzilla 1502312 None CLOSED Nothing in Fedora 27+ grub2 obsoletes/provides grub2-efi.i686 2019-04-02 05:14 UTC

Internal Trackers: 1491624 1502312

Description Jeremy Nickurak 2017-10-26 15:23:12 UTC
Description of problem:

When running system-upgrade on a UEFI-based F26 system to try to go to F27, I get errors about grub2-efi-modules requiring a particular version of grub2 which can't be provided. Interestingly,  http://rpmfind.net/linux/rpm2html/search.php?query=grub2-efi-modules doesn't seem to list such a package for f27 at all, so i was wondering if the package contents perhaps got rolled into a different package?

How reproducible:

100%, at least on this system.

Steps to Reproduce:
1. Attempt to run system-upgrade on my UEFI-based F26 system

Actual results:

sudo dnf system-upgrade download --releasever 27
Before you continue ensure that your system is fully upgraded by running "dnf --refresh upgrade". Do you want to continue [y/N]: yes
Fedora 27 - x86_64                                                                                                                                                                                                                             1.0 MB/s |  58 MB     00:59    
google-chrome-beta                                                                                                                                                                                                                             9.9 kB/s | 3.7 kB     00:00    
RPM Fusion for Fedora 27 - Free                                                                                                                                                                                                                571 kB/s | 970 kB     00:01    
RPM Fusion for Fedora 27 - Nonfree                                                                                                                                                                                                             226 kB/s | 224 kB     00:00    
Failed to synchronize cache for repo 'region51-chrome-gnome-shell', disabling.
Last metadata expiration check: 0:00:00 ago on 2017-10-26T08:55:00 MDT.
Error: 
 Problem: package grub2-efi-modules-1:2.02-0.40.fc26.x86_64 requires grub2-tools = 1:2.02-0.40.fc26, but none of the providers can be installed
  - grub2-tools-1:2.02-0.40.fc26.x86_64 does not belong to a distupgrade repository
  - problem with installed package grub2-efi-modules-1:2.02-0.40.fc26.x86_64

Expected results:

System successfully upgrades to F27.

Additional info:

This system was converted live from BIOS to UEFI under F26, so it's possible I left some packages installed that wouldn't typically be there from a fresh install -- that said, dnf distro-sync doesn't change anything.

I'm attempting to install a UEFI VM with a F27 netinstall to check whether this package is needed under F27.

Comment 1 Jeremy Nickurak 2017-10-26 16:42:08 UTC
Installing a F27 UEFI VM, it appears that grub2-efi-modules isn't present any more. The files it provided in /usr/lib/grub/x86_64-efi (for example, linux mod) aren't present.

My hunch is that grub2-efi-modules isn't needed any more. Indeed, I can remove it without breaking any dependencies. Maybe that package was left over from how I had the system migrated from BIOS to EFI, I'm not sure. I'm going to remove it, try rebooting, and then try upgrading.

Comment 2 Jeremy Nickurak 2017-10-26 16:57:59 UTC
I can confirm that my f26 system appears to boot normally without that package, so I'm proceeding with the upgrade, which does start downloading without flagging any more dependency issues.

I'm not sure if any other standand f26 systems would have that package, or why I had it, or why anyone would want it, but this is probably about as far as I can take my investigation.

Comment 3 Jeremy Nickurak 2017-10-26 21:41:49 UTC
Continuing with the upgrade left the system *unbootable*, and requiring manual repair.

I repaired it pretty manually, by booting a f26 livecd I had handy, starting a chroot to my installed (and upgraded to f27) filesystem (which appropriate bind-mounting of /dev/, etc), and attempted to reinstall grub (grub2-install /dev/sdb). This failed, because /usr/lib/grub/x86_64-efi/modinfo.sh was missing.

That appeared to be in grub2-efi-x64-modules. I ran a quick dnf update to get any updates that I missed in the system-upgrade, and then I attempted to run 'sudo dnf install grub2-efi-x64-modules.noarch grub2-efi-x64.x86_64', which failed with an error:

grub2-common = 1:2.02-18.fc27 is needed by grub2-efi-x64-modules-1:2.02-18.fc27.noarch
To diagnose the problem, try running: 'rpm -Va --nofiles --nodigest'.
You probably have corrupted RPMDB, running 'rpm --rebuilddb' might fix the issue.
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.

Instead, running 'sudo dnf install grub2-efi-x64-modules.noarch grub2-efi-x64.x86_64  grub2-common' instead allowed it to install. I re-ran grub2-install /dev/sdb, and reran grub2-mkconfig -o /boot/grub2/grub.cfg, which succeeded.

After that, the system booted into F27 (which apparently had been upgraded to successfully).

I hope there's some other evidence of efi-based upgrades from F26->F27 succeeding, and that mine was some kind of corner case.

Comment 4 Jeremy Nickurak 2017-10-26 21:43:51 UTC
(Nearly forgot -- in the "unbootable" state, what I observed was the system booting to a grub command line, where I didn't see an obvious way to proceed, couldn't find my configfile).

Comment 5 Jeremy Nickurak 2017-10-27 01:46:46 UTC
I have a 2nd uefi-based system, which was also a conversion from bios to efi, but converted a handful of dnf system-upgrades ago, all of which went fine, but seems to be hitting this issue.

Comment 6 Jeremy Nickurak 2017-10-27 15:04:13 UTC
My 2nd machine did need to remove that package to solve the dependency issue -- but then upgraded and booted fine. Not clear to me what the difference is/was.

Comment 7 Shatadru Bandyopadhyay 2017-11-02 02:46:09 UTC
Ditto, facing same issue.

 Problem 1: package grub2-efi-modules-1:2.02-0.40.fc26.x86_64 requires grub2-tools = 1:2.02-0.40.fc26, but none of the providers can be installed
  - grub2-tools-1:2.02-0.40.fc26.x86_64 does not belong to a distupgrade repository
  - problem with installed package grub2-efi-modules-1:2.02-0.40.fc26.x86_64

Comment 8 Andy 2017-11-08 15:30:47 UTC
Same here.

Comment 9 Chris Murphy 2017-11-11 19:35:03 UTC
I was able to get around this by first doing:
dnf remove grub2 grub2-efi-modules

Possible dups:
https://bugzilla.redhat.com/show_bug.cgi?id=1502312
https://bugzilla.redhat.com/show_bug.cgi?id=1491624

Comment 10 Andy 2017-11-14 15:52:50 UTC
Dear Chris.

Were you able to boot after removing grub2-efi-modules and upgrading?

Comment 11 Chris Murphy 2017-11-14 18:44:11 UTC
Yes. 

The grubx64.efi has modules baked into it for all Fedora supported configurations. The only reason to install grub2-efi-modules is to use an unsupported configuration, and this package is not installed by default. 

Plus the only way to use these modules is either manually copy their directory to the ESP where grux64.efi is, or stomp on that Fedora grubx64.efi by calling grub2-install to create a new one which of course has completely different behavior than the Fedora grubx64.efi (the grub2-install one behaves like upstream, it expects grub.cfg and grub modules to be in /boot/grub2, not on the ESP).

From
https://src.fedoraproject.org/cgit/rpms/grub2.git/tree/grub.macros

contains this line of modules included in grubx64.efi.

GRUB_MODULES="	all_video boot btrfs cat chain configfile echo	\\\
		efifwsetup efinet ext2 fat font gfxmenu gfxterm \\\
		gzio halt hfsplus iso9660 jpeg loadenv loopback \\\
		lvm lsefi mdraid09 mdraid1x minicmd		\\\
		normal part_apple part_msdos part_gpt		\\\
		password_pbkdf2 png reboot			\\\
		search search_fs_uuid search_fs_file		\\\
		search_label serial sleep syslinuxcfg test tftp \\\
		video xfs"

Comment 12 Chris Murphy 2017-11-15 01:57:53 UTC

*** This bug has been marked as a duplicate of bug 1491624 ***

Comment 13 Adam Williamson 2017-11-15 22:39:10 UTC
1491624 mentions two different and unrelated problems. One is this, the other is to do with a package abrt-java-connector . As this report is more correctly focused on solely the grub2-efi-modules issue, it'd be best to have this one as the main report, not 1491624. Thus, re-opening.

Comment 14 Adam Williamson 2017-11-15 22:40:58 UTC
Prior to the big grub2 rework - in grub2-2.02-8 and earlier - there was a package 'grub2-efi-modules'. After the rework, this package does not exist any more, but nothing else obsoletes or provides it. The package requires grub2-tools of the same EVR, so dnf chokes when attempting to upgrade any system which has grub2-efi-modules installed.

Comment 15 Adam Williamson 2017-11-15 22:46:09 UTC
BTW, I *strongly* recommend that nobody remove the grub2 or grub2-efi packages in an attempt to work around issues like this. It is very likely to cause problems in some cases. Please wait for pjones to address these problems properly.

Comment 16 Andrew Wippler 2017-11-17 15:02:14 UTC
FWIW, I encountered the same message on my Dell XPS 9560. Removing the package like Chris Murphy said removed the warning message and allowed the upgrade process to continue. I was also able to `sudo dnf system-upgrade reboot` and upgrade to F27 successfully.

I think the OP initial problem is that he rebooted into F26 after removing the package:

> I'm going to remove it, try rebooting, and then try upgrading.
(From comment #1)

...

Is there no current way to safely deprecate packages between versions of fedora? I think that is the underlying issue here.

Comment 17 Adam Williamson 2017-11-17 15:41:02 UTC
Sure there is. It just wasn't done.

Comment 18 Daibhidh 2017-11-19 01:46:10 UTC
I have the same problem.

# dnf upgrade --refreshLast metadata expiration check: 0:00:00 ago on Sun 19 Nov 2017 01:41:28 GMT.
Dependencies resolved.
Nothing to do.
Complete!
# sudo dnf system-upgrade download --releasever=27
Before you continue ensure that your system is fully upgraded by running "dnf --refresh upgrade". Do you want to continue [y/N]: y
Last metadata expiration check: 0:00:00 ago on Sun 19 Nov 2017 01:41:56 GMT.
Error: 
 Problem: package grub2-efi-modules-1:2.02-0.40.fc26.x86_64 requires grub2-tools = 1:2.02-0.40.fc26, but none of the providers can be installed
  - grub2-tools-1:2.02-0.40.fc26.x86_64 does not belong to a distupgrade repository
  - problem with installed package grub2-efi-modules-1:2.02-0.40.fc26.x86_64

Looking forward in anticipation of this problem being fixed :-).

Cheers.

Comment 19 Davide Maglio 2017-11-19 09:13:03 UTC
Same issue for me after a clean f26 install and upgrade. The laptop still reboot and i can see grub error about uncorrect bootorder. Same issue if i try a clean f26 install. Fedora is my only OS, i don't have any other OS

Comment 20 Muhammad Arif 2017-11-20 05:03:18 UTC
I encountered same issue and I noticed the package name has been changed from grub2-efi-modules (fedora 26) to grub2-efi-x64-modules (fedora 27). Somehow during grub2 installation, the upgrade is able to find grub name grub2-efi (fedora 26) to grub2-efi-x64 (fedora 27) but not grub2-efi-modules. Maybe word x64 was not supposed to be located between efi and modules in the naming? 

When I saw Jeremy comment, I think it's true.

So what I did is just upgrade normally using the normal method:

dnf upgrade --refresh
dnf install dnf-plugin-system-upgrade
dnf system-upgrade download --releasever=27
dnf system-upgrade reboot

But when error installing grub2-efi-modules dependencies, I just simply skipped/cancelled, instead, I run 

dnf remove grub2-efi-modules 

And continue with the upgrade. Let it reboot to finish the upgrade process. When it boot again, I chroot and install the grub2-efi-x64-modules (naming changed in fedora 27). Update grub mkconfig.

Final reboot, smooth boot up without other issue aside from that.

Regards

Comment 21 Davide Maglio 2017-11-20 09:31:33 UTC
(In reply to Muhammad Arif from comment #20)
> And continue with the upgrade. Let it reboot to finish the upgrade process.

When you try the first reboot after upgrade, still in reboot or complete correctly?

> Final reboot, smooth boot up without other issue aside from that.

After chroot do you have the Fedora entry in grub2?

Comment 22 Muhammad Arif 2017-11-21 08:37:22 UTC
(In reply to Davide Maglio from comment #21)
> (In reply to Muhammad Arif from comment #20)
> > And continue with the upgrade. Let it reboot to finish the upgrade process.
> 
> When you try the first reboot after upgrade, still in reboot or complete
> correctly?

After upgrade process finished, it will reboot itself. It shall failed, since I intentionally removed grub2-efi-modules beforehand. Only fixed with new grub2-efi-x64-modules package installation in chroot.

> 
> > Final reboot, smooth boot up without other issue aside from that.
> 
> After chroot do you have the Fedora entry in grub2?

Yes. Fedora 27 entry is there. All working perfectly along with other OS entries since I have those.

Regards

ps: Sorry if my English is not good.

Comment 23 Adam Williamson 2017-11-21 21:50:46 UTC
BTW, it'd be really useful if anyone who has grub2-efi-modules installed knows *why* they have it installed - what it's being used for. And whether that's something they set up manually or something Fedora set up for them. It is not currently clear (to me at least) whether there's some kind of relatively-commonly-encountered path which somehow results in grub2-efi-modules being installed and actually used, or if it's only people who are manually doing unusual stuff to their UEFI boot processes. (Peter, if you already know this, please tell me :>)

Comment 24 Davide Maglio 2017-11-21 22:37:41 UTC
(In reply to Muhammad Arif from comment #22)
> (In reply to Davide Maglio from comment #21)
> > (In reply to Muhammad Arif from comment #20)
> > > And continue with the upgrade. Let it reboot to finish the upgrade process.
> > 
> > When you try the first reboot after upgrade, still in reboot or complete
> > correctly?
> 
> After upgrade process finished, it will reboot itself. It shall failed,
> since I intentionally removed grub2-efi-modules beforehand. Only fixed with
> new grub2-efi-x64-modules package installation in chroot.
> 
> > 
> > > Final reboot, smooth boot up without other issue aside from that.
> > 
> > After chroot do you have the Fedora entry in grub2?
> 
> Yes. Fedora 27 entry is there. All working perfectly along with other OS
> entries since I have those.
> 
> Regards
> 
> ps: Sorry if my English is not good.

same issue... nothing changes...

Comment 25 Chris Murphy 2017-11-21 22:47:26 UTC
Speaking for myself and my vast experience with booting self torture, I've never seen grub2-efi-modules pulled in by anything. I've only ever manually installed it to do something completely batshit like hardware disable Radeon GPU before linux even boots, before we had vga switcheroo working; and testing bootloader scripts directly consumed by grub with the blscfg.mod which is not baked into the Fedora grub EFI osloader by default.

Comment 26 Davide Maglio 2017-11-21 22:55:21 UTC
same issue after a clean f27 install. I don't know how to get the Go ....

Comment 27 T.J. Rowe 2017-11-21 23:00:51 UTC
(In reply to Adam Williamson from comment #23)
> BTW, it'd be really useful if anyone who has grub2-efi-modules installed
> knows *why* they have it installed - what it's being used for. And whether
> that's something they set up manually or something Fedora set up for them.
> It is not currently clear (to me at least) whether there's some kind of
> relatively-commonly-encountered path which somehow results in
> grub2-efi-modules being installed and actually used, or if it's only people
> who are manually doing unusual stuff to their UEFI boot processes. (Peter,
> if you already know this, please tell me :>)

I've used the modules in the past in an experimental LUKS+btrfs /boot setup, whereby I used the ability of GRUB to read an encrypted /boot so long as all required modules are in the EFI partition.

So, I installed this package and manually copied all necessary modules (such as luks.mod and btrfs.mod) onto the EFI partition, then loaded the appropriate modules in my GRUB config.  Worked great, at least as an exercise.

My guess is that the intent of this package was as a support tool for folks playing with advanced GRUB features such as this.

Comment 28 Adam Williamson 2017-11-21 23:40:40 UTC
OK. So to be more precise with my advice from earlier - if you actually *know* what grub2-efi-modules is/was used for in your setup, you can probably make a sensible decision about whether it's safe to just remove it to make the upgrade go.

The straight dope - at least, as I understand it - is that the bits that were previously in that package are now in the various grub2-efi-(foo)-modules 'noarch' packages. The reasons for this rejigging are to do with supporting those weird machines which are basically 64-bit but have 32-bit UEFI firmwares.

If you know you actually need something that was previously in a grub2-efi-modules package for your system to boot, your mission is to figure out which grub2-efi-(foo)-modules package now contains that bit and ensure it's installed before you try to boot the system. Otherwise you're gonna be in trouble.

On the other hand, if you know for sure you *don't* need anything that was in grub2-efi-modules for your system to boot, it *is* safe to simply remove it in order to unblock the upgrade.

If you're not sure, my advice continues to be to stick on f26 and wait for pjones to figure something out.

Davide, if a fresh install of Fedora 27 is not booting on your system, then I don't think this bug is your problem exactly. You should probably file it separately...

Comment 29 Daniel Boiko 2017-11-23 12:21:22 UTC
Hi All, I have this is issue too.

When I removed package grub2-efi-modules my system can't boot.

To fix boot I was booted in LiveCD then reinstalled packages using this docs:
https://fedoraproject.org/wiki/GRUB_2

Now I'm waiting for fix :(

Maybe some one can give good docs around EFI, Grub2, SecureBoot and how it works in Fedora(or any other distro)

Also I can help with testing, if needed.

Comment 30 Adam Williamson 2017-11-23 17:35:26 UTC
Daniel: by default, in a Fedora UEFI install, grub2-efi-modules is not installed and nothing from it is used during boot. You have to do *something* other than an out-of-the-box install to cause it to be used as part of the boot process. Can you think what you might have done that resulted in that?

Comment 31 Steve Elliott 2017-11-25 00:25:03 UTC
(In reply to Adam Williamson from comment #23)
> BTW, it'd be really useful if anyone who has grub2-efi-modules installed
> knows *why* they have it installed - what it's being used for. And whether
> that's something they set up manually or something Fedora set up for them.
> It is not currently clear (to me at least) whether there's some kind of
> relatively-commonly-encountered path which somehow results in
> grub2-efi-modules being installed and actually used, or if it's only people
> who are manually doing unusual stuff to their UEFI boot processes. (Peter,
> if you already know this, please tell me :>)

My F26 installation has insmod entries for modules supplied by grub2-efi-modules.

I am not aware that I have done any special configuration but dual booting & multiple graphics cards may have required some historical manual work.


[steve@colt ~]$ grep insmod /boot/grub2/*.cfg | sort | uniq
    insmod all_video
    insmod efi_gop
    insmod efi_uga
	insmod ext2
	insmod fat
	insmod gzio
    insmod ieee1275_fb
	insmod part_gpt
    insmod vbe
    insmod vga
    insmod video_bochs
    insmod video_cirrus

[steve@colt ~]$ sudo rpm -q -l grub2-efi-modules-1\:2.02-0.40.fc26.x86_64 | grep --regexp=video --regexp=efi_ --regexp=ext2 --regexp=fat --regexp=gz --regexp=_gpt
/usr/lib/grub/x86_64-efi/all_video.mod
/usr/lib/grub/x86_64-efi/all_video.module
/usr/lib/grub/x86_64-efi/efi_gop.mod
/usr/lib/grub/x86_64-efi/efi_gop.module
/usr/lib/grub/x86_64-efi/efi_uga.mod
/usr/lib/grub/x86_64-efi/efi_uga.module
/usr/lib/grub/x86_64-efi/exfat.mod
/usr/lib/grub/x86_64-efi/exfat.module
/usr/lib/grub/x86_64-efi/ext2.mod
/usr/lib/grub/x86_64-efi/ext2.module
/usr/lib/grub/x86_64-efi/fat.mod
/usr/lib/grub/x86_64-efi/fat.module
/usr/lib/grub/x86_64-efi/fixvideo.mod
/usr/lib/grub/x86_64-efi/fixvideo.module
/usr/lib/grub/x86_64-efi/gzio.mod
/usr/lib/grub/x86_64-efi/gzio.module
/usr/lib/grub/x86_64-efi/part_gpt.mod
/usr/lib/grub/x86_64-efi/part_gpt.module
/usr/lib/grub/x86_64-efi/video.lst
/usr/lib/grub/x86_64-efi/video.mod
/usr/lib/grub/x86_64-efi/video.module
/usr/lib/grub/x86_64-efi/video_bochs.mod
/usr/lib/grub/x86_64-efi/video_bochs.module
/usr/lib/grub/x86_64-efi/video_cirrus.mod
/usr/lib/grub/x86_64-efi/video_cirrus.module
/usr/lib/grub/x86_64-efi/video_colors.mod
/usr/lib/grub/x86_64-efi/video_colors.module
/usr/lib/grub/x86_64-efi/video_fb.mod
/usr/lib/grub/x86_64-efi/video_fb.module
/usr/lib/grub/x86_64-efi/videoinfo.mod
/usr/lib/grub/x86_64-efi/videoinfo.module
/usr/lib/grub/x86_64-efi/videotest.mod
/usr/lib/grub/x86_64-efi/videotest.module
/usr/lib/grub/x86_64-efi/videotest_checksum.mod
/usr/lib/grub/x86_64-efi/videotest_checksum.module

Comment 32 Adam Williamson 2017-11-25 00:48:21 UTC
As Chris noted in #c11, "The grubx64.efi has modules baked into it for all Fedora supported configurations." I think those modules are among those 'baked in', *as well as* being present as files in grub2-efi-modules.

Comment 33 Steve Elliott 2017-11-25 01:17:15 UTC
(In reply to Adam Williamson from comment #32)
> As Chris noted in #c11, "The grubx64.efi has modules baked into it for all
> Fedora supported configurations." I think those modules are among those
> 'baked in', *as well as* being present as files in grub2-efi-modules.

It looks like somewhere along the way shim.efi has been used instead of grubx64.efi.
(Or perhaps I misunderstand the boot sequence!)

[steve@colt ~]$ cat /boot/efi/EFI/fedora/BOOT.CSV 
shim.efi,Fedora,,This is the boot entry for Fedora

Comment 34 Adam Williamson 2017-11-25 17:59:13 UTC
the firmware loads shim, shim loads grub.

Comment 35 Stanislav Graf 2017-11-25 19:39:24 UTC
After an update using GNOME Software app, Fedora 27 didn't boot (even no OS selection), I got stuck with grub2 prompt. As a fix I had to boot using F27 live CD, chroot into my system, and install package grub2-efi-x64-modules. No other configuration or setting or changes was needed. I just installed that one pkg. After reboot, OS selection menu was back and I was able to boot upgraded F27.

Comment 36 Chris Murphy 2017-11-25 20:43:08 UTC
(In reply to Stanislav Graf from comment #35)
> As a fix I had to boot using F27 live CD, chroot into my system, and install package grub2-efi-x64-modules.

What are the insmod lines in your grub.cfg? If you compare those to the list of modules starting on line 325 http://pkgs.fedoraproject.org/cgit/rpms/grub2.git/tree/grub.macros; it's plausible the grub2-mkconfig is trying to pull in modules that are not built in for some obscure reason that just hasn't come up in normal testing *shrug*.

Comment 37 Simone 2017-11-26 10:13:39 UTC
A hit this bug after having tried a system-upgrade (on a fresh installed Fedora-LXQt-Live-i386-26). The ISO was downloaded from https://torrent.fedoraproject.org/.

Comment 38 Stanislav Graf 2017-11-27 19:26:49 UTC
(In reply to Chris Murphy from comment #36)
> (In reply to Stanislav Graf from comment #35)
> > As a fix I had to boot using F27 live CD, chroot into my system, and install package grub2-efi-x64-modules.
> 
> What are the insmod lines in your grub.cfg? If you compare those to the list
> of modules starting on line 325
> http://pkgs.fedoraproject.org/cgit/rpms/grub2.git/tree/grub.macros; it's
> plausible the grub2-mkconfig is trying to pull in modules that are not built
> in for some obscure reason that just hasn't come up in normal testing
> *shrug*.

I found out grub2-efi-x64-modules is not needed at all :( It seems I've hit this F27 common bug instead - bug 1227736. I have xfs for /boot and the fact I mounted /boot in chroot fixed probably the issue by replaying journal. I have uninstalled grub2-efi-x64-modules and all works as expected.

Comment 39 Andrew Wippler 2017-11-27 20:00:04 UTC
IIRC, I installed grub2-efi-modules when I could not launch grub with SecureBoot. I received some error concerning efi (which I googled) and the answer was to install the missing efi modules (it sounded logical). 

Unfortunately by installing the package, it did not solve my issues and I ended up disabling SecureBoot in my BIOS.

Comment 40 Daibhidh 2017-11-27 21:56:34 UTC
I removed grub2-efi-modules only from my F26 without any apparent ill effects - the system could be subsequently rebooted into F26 without any problem. And then, of course, the upgrade error went away, and I was able to upgrade to F27.

Comment 41 Cott Lang 2017-11-29 15:30:36 UTC
fwiw, I require efi modules but worked around it with:

dnf --releasever=27 --setopt=deltarpm=false distro-sync --allowerasing
dnf install grub2-efi-x64-modules
<reboot>

I don't recommend this if you're not comfortable recovering from a boot failure. :)

Comment 42 Adam Williamson 2017-11-29 16:53:16 UTC
If anyone else tries that, please at least do it from something like a tmux/screen session running on a vt. Don't do it from a shell within a graphical environment.

Comment 43 Robb Romans 2017-12-01 00:22:39 UTC
I received the same warning when beginning the upgrade. I stopped the upgrade pending resolution. My F26 system boots through UEFI.

Comment 44 Robb Romans 2017-12-01 20:57:40 UTC
Removing grub2-efi-modules and then manually upgrading worked for me.

Comment 45 John Haiducek 2017-12-06 06:03:06 UTC
(In reply to Adam Williamson from comment #23)
> BTW, it'd be really useful if anyone who has grub2-efi-modules installed
> knows *why* they have it installed - what it's being used for. And whether
> that's something they set up manually or something Fedora set up for them.
> It is not currently clear (to me at least) whether there's some kind of
> relatively-commonly-encountered path which somehow results in
> grub2-efi-modules being installed and actually used, or if it's only people
> who are manually doing unusual stuff to their UEFI boot processes. (Peter,
> if you already know this, please tell me :>)

My F26 installation appears to be bringing in a bunch of modules provided by grub2-efi-modules. I do not recall manually adding any of them to the file. My system is dual-boot (the other OS is MacOS). The system has been upgraded in stages since Fedora 20 or so.

$ sudo grep insmod /boot/efi/EFI/fedora/grub.cfg|sort|uniq

   insmod all_video
    insmod efi_gop
    insmod efi_uga
		insmod ext2
	insmod ext2
insmod ext2
  insmod gettext
  insmod gfxterm
		insmod gzio
	insmod gzio
    insmod hfsplus
    insmod ieee1275_fb
insmod lvm
		insmod part_gpt
	insmod part_gpt
insmod part_gpt
    insmod vbe
    insmod vga
    insmod video_bochs
    insmod video_cirrus

Comment 46 Adam Williamson 2017-12-07 19:29:53 UTC
John: see the above discussion - AIUI, several modules are provided in grub2-efi-modules , but they are *also* baked directly into the grubx64.efi executable, as stated by cmurf in comment #11. You're only in trouble if you use modules that are *not* baked into grubx64.efi . I'm not sure if we have a list of those modules - Chris, do we have one, or know how to get one?

Comment 47 Chris Murphy 2017-12-07 19:41:07 UTC
Comment 11 has the URL and the list of modules. 

If your grub.cfg references a module to insert with insmod command that isn't in that list, you could press 'c' at the GRUB menu and manually do insmod <modulename> and see if you get an error.

That grub.cfg uses insmod for a particular module doesn't tell us whether the module is already loaded, grub-mkconfig only ever assumes normal.mod is loaded. e.g. you'll note grub.cfg includes multiple insmod ext2, even though obviously on 99.9% of Fedora installations /boot is on ext4, and GRUB was able to get this far already means it has ext2 module loaded (because it's baked in).

Comment 48 Jonas L. B. 2017-12-11 20:41:53 UTC
I also ran into this issue, and was able to fix the problem by simply removing the package. Like others, I could not remember doing any manual changes, however, it turns out I likely migrated this system to EFI manually this summer (for some reason that I don't remember):

$ sudo yum history grub2-efi-modules

ID     | Command line             | Date and time    | Action(s)      | Altered
-------------------------------------------------------------------------------
   106 | remove grub2-efi-modules | 2017-12-11 20:07 | Erase          |    1
    13 | install grub2-efi grub2- | 2017-07-21 20:45 | Install        |    1

Installing grub2-efi-modules is recommended by Fedora Wiki, https://fedoraproject.org/wiki/GRUB_2 (under "Install bootloader files"). It is likely that I likely just did as it recommended.

My "insmod"-list looked similar to that of John in Comment 45 (i had fewer though). 
Many (in my case, all) of these modules are not in the list of Comment 11.
However, in grub.cfg, they are inside an else-statement for the case that all_video does not exist (but as all_video is in the list from Comment 11, I assume it is always loaded over the others).
This made me confident enough to dare the removal of the package. And it worked.

Comment 49 Jonas L. B. 2017-12-11 20:44:40 UTC
Sorry for the extra message, but I messed up some formulation regarding the modules in grub.cfg. What I mean is, that in my case, all of the modules in that file, which are not in the list of Comment 11, were inside an else-statement and likely not loaded.

Comment 50 Chris Murphy 2017-12-11 21:57:07 UTC
(In reply to Jonas L. B. from comment #48)

> Installing grub2-efi-modules is recommended by Fedora Wiki,
> https://fedoraproject.org/wiki/GRUB_2 (under "Install bootloader files"). It
> is likely that I likely just did as it recommended.

Fair enough. Looks like this is the change that added that.
Revision as of 10:51, 12 March 2015 (view source)
Martijn (talk | contribs)
(→‎Install the bootloader files: took me a long while to figure out why grub2-install kept complaining about missing /usr/lib/grub/x86_64-efi ...)

One user had a special requirement that possibly he didn't know about, and then made general advice to install the modules.

Comment 51 Chris Murphy 2017-12-11 22:45:40 UTC
I've changed the wiki thusly:
https://fedoraproject.org/w/index.php?title=GRUB_2&diff=prev&oldid=507428

Comment 52 Adam Williamson 2017-12-14 02:11:14 UTC
Thanks a lot for digging out that wiki page and fixing it, guys - that could certainly have been part of the problem here. I do intend to try and find a minute to dig into whether the package could have been installed via obsoletes/provides at some point, too.

Comment 53 donatom 2017-12-15 17:29:28 UTC
I have the same problem with grub-efi-modules. I don't recall adding any extra grub programs (like grub-efi-modules). But when I did a system-upgrade from Fedora 22 to Fedora 23 grub was borked and so was the windows efi partition (it was corrupted and eventually fixed with fsck for fat). I reinstalled grub-efi several times until I found that the efi partition was corrupted. I followed the fedora grub-efi wiki, so if it said to install grub-efi-modules then that is what I did (I can't recall the details). I guess I will wait to see if this problem is fixed before attempting dnf system-upgrade.

Comment 54 PA 2018-01-07 18:11:09 UTC
Same error, see system info and the ultimate error below:
4.14.11-200.fc26.x86_64 #1 SMP Wed Jan 3 13:58:53 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

sudo lscpu

Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Vendor ID:           GenuineIntel
Model name:          Intel(R) Core(TM)2 Duo CPU     T9550  @ 2.66GHz

Ran repolist

Ran cleanall

Ran grub2-mkconfig -o /boot/grub2/grub.cfg

Ran distrosync

Ran removeall

All prior to:

sudo dnf upgrade --refresh
Last metadata expiration check: 0:00:00 ago on Sun 07 Jan 2018 08:47:17 PM EAT.
Dependencies resolved.
Nothing to do.
Complete!

sudo dnf install dnf-plugin-system-upgrade
Last metadata expiration check: 0:02:40 ago on Sun 07 Jan 2018 08:47:17 PM EAT.
Package python3-dnf-plugin-system-upgrade-2.0.4-1.fc26.noarch is already installed, skipping.
Dependencies resolved.
Nothing to do.
Complete! 

sudo dnf system-upgrade download --releasever=27
Before you continue ensure that your system is fully upgraded by running "dnf --refresh upgrade". Do you want to continue [y/N]: y
Failed to synchronize cache for repo 'rpmfusion-nonfree-updates', disabling.
Last metadata expiration check: 0:00:00 ago on Sun 07 Jan 2018 08:51:16 PM EAT.
Error: 
 Problem: package grub2-efi-modules-1:2.02-0.40.fc26.x86_64 requires grub2-tools = 1:2.02-0.40.fc26, but none of the providers can be installed
  - grub2-tools-1:2.02-0.40.fc26.x86_64 does not belong to a distupgrade repository
  - problem with installed package grub2-efi-modules-1:2.02-0.40.fc26.x86_64 

Noticed an error in synchronizing the cache, re-ran the same command:
Before you continue ensure that your system is fully upgraded by running "dnf --refresh upgrade". Do you want to continue [y/N]: y
Last metadata expiration check: 0:00:00 ago on Sun 07 Jan 2018 09:06:23 PM EAT.
Error: 
 Problem: package grub2-efi-modules-1:2.02-0.40.fc26.x86_64 requires grub2-tools = 1:2.02-0.40.fc26, but none of the providers can be installed
  - grub2-tools-1:2.02-0.40.fc26.x86_64 does not belong to a distupgrade repository
  - problem with installed package grub2-efi-modules-1:2.02-0.40.fc26.x86_64

This error is reproducible on this system. Have not currently taken any action to remove grub2. Did NOT use UEFI. Any solution/advice would be appreciated.

Comment 55 Adam Williamson 2018-01-08 19:36:54 UTC
PA: if you're very sure your system does not boot via UEFI, it should be quite safe to remove the grub2-efi-modules package to allow the upgrade to run.

Comment 56 Fedora Update System 2018-01-18 19:22:23 UTC
grub2-2.02-21.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-fbcc83aa97

Comment 57 Fedora Update System 2018-01-18 19:23:07 UTC
grub2-2.02-21.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-fbcc83aa97

Comment 58 Fedora Update System 2018-01-19 16:34:32 UTC
grub2-2.02-21.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-fbcc83aa97

Comment 59 Adam Williamson 2018-01-20 01:59:52 UTC
Unfortunately, Peter, it looks like the changes introduced to try and fix this have broken live image compose for Rawhide:

https://kojipkgs.fedoraproject.org//work/tasks/9587/24299587/livemedia-out.log

2018-01-19 12:06:10,666 INFO livemedia-creator: dnf.exceptions.Error: Transaction check error:
2018-01-19 12:06:10,666 INFO livemedia-creator: file /boot/efi/EFI/fedora conflicts between attempted installs of fwupdate-efi-10-1.fc28.x86_64 and grub2-common-1:2.02-22.fc28.noarch
2018-01-19 12:06:10,666 INFO livemedia-creator: file /boot/efi/EFI/fedora conflicts between attempted installs of grub2-efi-x64-1:2.02-22.fc28.x86_64 and fwupdate-efi-10-1.fc28.x86_64
2018-01-19 12:06:10,666 INFO livemedia-creator: file /boot/efi/EFI/fedora/fonts conflicts between attempted installs of grub2-efi-x64-cdboot-1:2.02-22.fc28.x86_64 and grub2-efi-ia32-1:2.02-22.fc28.x86_64
2018-01-19 12:06:10,666 INFO livemedia-creator: file /boot/efi/EFI/fedora/fonts/unicode.pf2 conflicts between attempted installs of grub2-efi-x64-cdboot-1:2.02-22.fc28.x86_64 and grub2-efi-ia32-1:2.02-22.fc28.x86_64

Comment 60 Adam Williamson 2018-01-20 02:01:21 UTC
Note: no compose has run with -23 yet. I'm not sure from the change description between -22 and -23 whether -23 would fix this.

Comment 61 Fedora Update System 2018-01-23 21:37:44 UTC
grub2-2.02-22.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-fbcc83aa97

Comment 62 Fedora Update System 2018-01-25 08:36:28 UTC
grub2-2.02-22.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-fbcc83aa97

Comment 63 Adam Williamson 2018-02-06 15:41:14 UTC
Update can probably be pushed now? Feedback looks good.

Comment 64 Fedora Update System 2018-02-14 17:26:50 UTC
grub2-2.02-22.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.


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