Bug 1506704
Summary: | Nothing in Fedora 27+ grub2 obsoletes/provides grub2-efi-modules (breaks upgrades) | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Jeremy Nickurak <redhat-bugs> |
Component: | grub2 | Assignee: | Peter Jones <pjones> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | 27 | CC: | 31337shadowstalker, ajschult784, andrew.wippler, angelfromunova, awilliam, bugzilla, cegolf, chanueting, cott, dgmorris, dmaglio, donatom.martino, drixi.b, esteban.xandri, FunkMasterKiwi, hugh, jhaiduce, ljn917, lkundrak, pjones, rbottomley, rds, redhat-bugs, redhat, robb, sbandyop, sgraf, simone.spam, Simon.Gerhards, SteveCGElliott, thomas |
Target Milestone: | --- | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | grub2-2.02-22.fc27 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2018-02-14 17:26:50 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Jeremy Nickurak
2017-10-26 15:23:12 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. 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. 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. (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). 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. 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. 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 Same here. 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 Dear Chris. Were you able to boot after removing grub2-efi-modules and upgrading? 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" *** This bug has been marked as a duplicate of bug 1491624 *** 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. 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. 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. 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. Sure there is. It just wasn't done. 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. 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 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 (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? (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. 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 :>) (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... 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. same issue after a clean f27 install. I don't know how to get the Go .... (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. 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... 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. 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? (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 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. (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 the firmware loads shim, shim loads grub. 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. (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*. 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/. (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. 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. 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. 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. :) 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. I received the same warning when beginning the upgrade. I stopped the upgrade pending resolution. My F26 system boots through UEFI. Removing grub2-efi-modules and then manually upgrading worked for me. (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 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 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). 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. 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. (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. I've changed the wiki thusly: https://fedoraproject.org/w/index.php?title=GRUB_2&diff=prev&oldid=507428 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. 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. 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. 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. grub2-2.02-21.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-fbcc83aa97 grub2-2.02-21.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-fbcc83aa97 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 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 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. grub2-2.02-22.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-fbcc83aa97 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 Update can probably be pushed now? Feedback looks good. 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. |