Bug 1917213 - [RFE] grub2-install fails, complains about secure boot.
Summary: [RFE] grub2-install fails, complains about secure boot.
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: grub2
Version: 34
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1948256 1948731 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-01-18 03:24 UTC by Valdis Kletnieks
Modified: 2022-05-12 16:23 UTC (History)
26 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug


Attachments (Terms of Use)

Description Valdis Kletnieks 2021-01-18 03:24:59 UTC
Description of problem:
I have a laptop that on occasion apparently corrupts the EFI variables so it won't boot. Booting from a rescue disk and running "grub2-install /dev/sda" fixes the problem.

However, the latest release complains:

grub2-install: error: this utility cannot be used for EFI platforms because it does not support UEFI Secure Boot.

Backlevelling to 2.04-31.fc34 makes it work again. This was particularly annoying because I don't even have Secure Boot enabled on this laptop.

Version-Release number of selected component (if applicable):
2.04-34.fc34

How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Ben Cotton 2021-02-09 15:40:58 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle.
Changing version to 34.

Comment 2 Chris Murphy 2021-02-15 02:38:59 UTC
Pretty sure this is intentional.

The grub2-efi-x64 package contains the grux64.efi built and signed by Fedora. That's the bootloader that should be used and is supported. The problem with grub2-install on UEFI is it creates a local, custom, non-signed grubx64.efi that we can't test, and ends up having different behavior than the Fedora built one. 

I suggest reinstalling the bootloaders so you're using what we can practically test and support:

sudo dnf reinstall grub2-efi-x64 shim-x64

And for manipulating NVRAM boot parameters, that's efibootmgr. Depending on the nature of the bug, one of two things should work: remove all the boot entries, and shim will boot by default and add a proper Fedora entry to NVRAM when it's missing; or you can remove the non-working entry and replace it with a working entry: grep efibootmgr /var/log/anaconda/storage.log, will show the original command used at the time of installation. Don't forget the path needs double \.

Comment 3 fedora 2021-03-25 02:10:57 UTC
It would be great if there was a either a flag to bypass the check in this patch (https://src.fedoraproject.org/rpms/grub2/blob/rawhide/f/0166-grub-install-disable-support-for-EFI-platforms.patch#_43) or if the patch actually checked if Secure boot was even enabled before refusing to install grub.

Existing installation procedures that uses grub2-install to install the bootloader (such as a chroot-based installation) will now fail as a result of the above patch introduced in fedora 34

Comment 4 Ali 2021-04-13 07:34:16 UTC
This doesn't even respect grub2-install's `--force` option ... so basically you've just decided to break all existing installations that don't even use secure boot, overnight ...
at least enable the users to bypass this using grub2-install's `--force` option.

Comment 5 Javier Martinez Canillas 2021-04-13 08:05:26 UTC
Why do you need grub2-install on EFI ? To create the EFI boot entry ?

Comment 6 Javier Martinez Canillas 2021-04-13 08:07:41 UTC
(In reply to fedora from comment #3)
> It would be great if there was a either a flag to bypass the check in this
> patch
> (https://src.fedoraproject.org/rpms/grub2/blob/rawhide/f/0166-grub-install-
> disable-support-for-EFI-platforms.patch#_43) or if the patch actually
> checked if Secure boot was even enabled before refusing to install grub.
>

Even if Secure Boot is not enabled, executing grub2-install will not allow to
be enabled later. So a user that has SB disabled, could execute grub2-install
which will break the setup and prevent the machine to boot if SB is enabled.

Comment 7 Javier Martinez Canillas 2021-04-13 08:08:35 UTC
(In reply to Ali from comment #4)
> This doesn't even respect grub2-install's `--force` option ... so basically
> you've just decided to break all existing installations that don't even use
> secure boot, overnight ...
> at least enable the users to bypass this using grub2-install's `--force`
> option.

Allowing to be executed when using the --force option makes sense to me.

Comment 8 Eugene A. Pivnev 2021-04-13 10:12:59 UTC
Fedora 33 at MacBook mid 2012 - same problem.
After today's dnf update

Comment 9 Chris Murphy 2021-04-13 17:40:48 UTC
@ti.eugene@gmail.com that 2012 Macbook doesn't support UEFI Secure Boot. I think what you might be experiencing is: boot chime->gray screen->indefinite hang. Is that correct? If so, see bug 1949210. There is a work around there. If that is not the problem you're experiencing, could you be more specific with what you do see? grub2-install shouldn't be necessary on Macs either, the grub2-efi-x64-2.06~rc1-4.fc34.x86_64 package contains a prebaked grubx64.efi bootloader that will boot Macs.

Comment 10 Eugene A. Pivnev 2021-04-13 19:49:28 UTC
I don't know anything about gray screen.
As F33 installer couldn't mount this macbook's EFI partition I installed it via dump|restore and grub2-install after this.
It worked ok (but sometimes, after _some_ Fedora updates and _each_ macOS update) grub2 loader ended with `grub>`.
I just started with F33 live USB and grub2-install again.
But today after dnf update (and new kernel) - `grub>` and `grub2-install cannot blah-blah-blah`.

Comment 11 Chris Murphy 2021-04-13 21:15:36 UTC
Eugene, grub2-install shouldn't be used on any (U)EFI computers. The correct procedure for reinstalling the bootloaders on Macs and other (U)EFI computers is:

sudo dnf reinstall shim-* grub2-*

Fedora 33 and older:
sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

Fedora 34 and newer:
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

In the usual case, none of this should be necessary anymore because grub.cfg is static and unchanging. The real bootloader configuration files when kernels are added/removed are located in /boot/loader/entries/.

For the case of buggy firmware corrupting NVRAM entries, instead of using grub2-install, use efibootmgr --bootorder to make sure the correct boot entry you want (for Fedora's shim) has its boot entry number listed first in boot order. If the entry is missing, you can find the proper command to use with 'grep efibootmgr /var/log/anaconda/storage.log' remembering to add an extra \ character to escape the ones found in the log.

In very unusual cases, some specific use cases might need GRUB modules not included in the Fedora pre-created grubx64.efi file; in that case there is a separate modules package to install and copy the modules into the correct location, rather than using grub2-install.

Comment 12 Eugene A. Pivnev 2021-04-14 00:17:33 UTC
I'm sorry for misguiding, I wrote too short comment.
In real life my `grub2-install` is:
`grub2-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=Fedora --recheck --debug`
And many line before and after this (like mounting EFI partition, efivars etc):
https://tieugene.fedorapeople.org/fix_makbook.sh

Fedora stay #0000 in bootorder but not shown in Macbook EFI menu. Maybe because of numeration (macOS and Windows starts from 0080 but Fedora - from 0000) or I don't know why.
Anyway Fedora grub starts 1st if Alt key not pressed.
_Was_ starting till yesterday.

Comment 13 Chris Murphy 2021-04-14 01:28:59 UTC
Eugene, it probably broke in an update yesterday because your custom grubx64.efi was replaced by the correct Fedora grubx64.efi. On Fedora 33, that grubx64.efi expects to see the grub.cfg in /boot/efi/EFI/fedora/ but in your custom configuration it's on /boot/grub/2 so it couldn't be found and chances are that's why you couldn't boot.

Fedora simply doesn't have the resources to support arbitrary custom configurations. We need fewer exceptions to the rule, and yeah there's a need for more contributions for better documentation so users can figure out how to repair things if they break. But a custom grubx64.efi isn't the way to get better stability, so all my advice in comment 11 still applies. If the GRUB2 maintainer wants to add a --force option so grub2-install can worked, it's up to the maintainer to do it. My opinion is it's reasonable for Fedora to drop all customization support in the bootloaders (all of them, not just GRUB) and if users have unusual custom requirements, they can compile GRUB upstream from source and get support for custom features from upstream. GRUB is too complex to support all possible use cases.

If there is a bug with the default installation not working correctly, then that should be fixed. By default grub2-install on UEFI hasn't ever been supported in Fedora, we've always had a Fedora built grubx64.efi bootloader installed. Thanks.

Comment 14 Pierre Juhen 2021-04-14 11:44:15 UTC
Same issue on fedora 33, after upgrade on grub 2.0.6

Downgrading to 2.04 solves the issue.

Same issue on 2 different PCs, one with secure boot enabled, one with secure boot disabled.

Comment 15 Jet Walsh 2021-04-14 16:05:05 UTC
I have a similar problem. Dell XPS 7390 2-in-1 with Secure Boot enabled (no customization...default everything). Ran dnf update, rebooted, and could not get to the Secure Boot screen. Downgraded to grub2-efi-x64-2.06~rc1-3.fc34.x86_64...no joy. Ended up finding the culprit to be shim-x64-15-8.x86_64 and downgraded it to 4-3. Hopefully this info is helpful.

Comment 16 Aki Ketolainen 2021-04-14 18:14:55 UTC
I have an Apple iMac from 2011. It has a VFAT EFI system partition. 

The Fedora and CentOS installers don't know how to handle that and output:

"EFI System Partition cannot be of type efi."

I have been able to run the installer successfully by unselecting installing the boot loader
while installing and then after install, do the chroot & grub2-install thing.

How am I going to install Fedora onto this machine after this change to grub2-install ?

I talked about this on Freenode #fedora but got a response almost as if I was accused of lying about the setup.

Comment 17 Chris Murphy 2021-04-14 19:52:32 UTC
(In reply to Aki Ketolainen from comment #16)
> I have an Apple iMac from 2011. It has a VFAT EFI system partition. 
> 
> The Fedora and CentOS installers don't know how to handle that and output:
> 
> "EFI System Partition cannot be of type efi."

Choose "Linux HFS+ ESP" in the File System pop-up menu.

That will enable a feature in the Mac's firmware so you can choose between Fedora and MacOS by holding the option key at the boot chime. It'll look like this:
https://photos.app.goo.gl/VFhXJH7caNmMyAAz7

You can also use 'efibootmgr --bootorder or --bootnext' to specify a four digit boot entry associated with the OS you want to boot.

Comment 18 Aki Ketolainen 2021-04-14 22:14:25 UTC
Thank Chris for helping out with my iMac. I left the VFAT ESP as is on the disk and created /dev/sda2 as "Linux HFS+ ESP" and after that the installer did its thing and the iMac booted to grub and Fedora 33.

Comment 19 Eugene A. Pivnev 2021-04-16 14:26:58 UTC
(In reply to Chris Murphy from comment #13)
> Eugene, it probably broke in an update yesterday because your custom
> grubx64.efi was replaced by the correct Fedora grubx64.efi. On Fedora 33,
> that grubx64.efi expects to see the grub.cfg in /boot/efi/EFI/fedora/ but in
> your custom configuration it's on /boot/grub/2 so it couldn't be found and
> chances are that's why you couldn't boot.

As I always update my host exactly with 'dnf update' and repair boot exactly with 'grub2-install':
- naturally I have just Fedora's grubx64.efi (as old as new) but no one 'custom'
- path to fedora EFI things is naturally /boot/efi/EFI/fedora/ as it is hardcoded in grub2* as you noted above.
Problem is not in file or path.

'...this utility cannot be used for EFI platforms because it does not support UEFI Secure Boot'.

Utility no supports.

Comment 20 Eugene A. Pivnev 2021-04-16 14:49:43 UTC
(In reply to Pierre Juhen from comment #14)
> Same issue on fedora 33, after upgrade on grub 2.0.6
> 
> Downgrading to 2.04 solves the issue.
> 
> Same issue on 2 different PCs, one with secure boot enabled, one with secure
> boot disabled.

I confirm - downgrading grub2* from 2.06* to 2.04 solved the problem.
MacBook Pro mid 2012.

Comment 21 Ali 2021-04-16 18:50:20 UTC
(In reply to Chris Murphy from comment #13)
> Eugene, it probably broke in an update yesterday because your custom
> grubx64.efi was replaced by the correct Fedora grubx64.efi. On Fedora 33,
> that grubx64.efi expects to see the grub.cfg in /boot/efi/EFI/fedora/ but in
> your custom configuration it's on /boot/grub/2 so it couldn't be found and
> chances are that's why you couldn't boot.
> 
> Fedora simply doesn't have the resources to support arbitrary custom
> configurations. 
While I agree with that, there is no need to impose arbitrary limitations either. there are a multitude of people out there that don't use secure boot and grub2-install works for their use-case perfectly fine ...
the method that you described has many problems and limitations ... for one, it doesn't work when you are offline and don't have access to repositories. and secondly, in my experience it has issues when your /boot is encrypted.

Comment 22 Chris Murphy 2021-04-16 19:52:53 UTC
(In reply to Ali from comment #21)
> While I agree with that, there is no need to impose arbitrary limitations
> either. 

subjective != arbitrary

The reality is that in the decade since GRUB 2, and the grub-install and grub-mkconfig scripts, users still get into trouble, it requires esoteric knowledge to fix things once they are in trouble, etc. I would consider it a failed paradigm as evidenced by how often *users* break their own systems and then can't fix them. Fedora's GRUB documentation has recommended to NOT use grub2-install on EFI for around a decade as well, and yet users still do it as evidenced by this bug.

>there are a multitude of people out there that don't use secure boot
> and grub2-install works for their use-case perfectly fine ...

The Fedora created grub$ARCH.efi works for their use case perfectly fine without requiring grub-install. We need to focus on robust interoperable approaches rather than expecting users to bring out a sledgehammer to "fix" things, which invariably ends up breaking other things.

>Using the 
> the method that you described has many problems and limitations ... for one,
> it doesn't work when you are offline and don't have access to repositories.

That's a valid point, and we probably should have the grub2-efi-$arch.rpm install a copy of its EFI OSLoader into /usr so that it can just be copied over to the ESP. But eventually this is what's intended with bootupd anyway. Realistically, users shouldn't have to know different commands for fixing/repairing bootloader setup on UEFI or BIOS.

> and secondly, in my experience it has issues when your /boot is encrypted.

The copy over method is significantly less fragile and complex for this use case than grub-install. All you have to do is strace grub-install or grub-mkconfig, and see how massively complicated all of those scripts are.

Anyway, I'm happy to debate these things on fedora-devel@ list or on #fedora on IRC. But I don't think it's going to progress this bug report.

Comment 23 Zoltan Boszormenyi 2021-04-19 08:26:13 UTC
Now grub2-install fails even when running against a USB pendrive with --removable.
That should be possible to do.

Comment 24 Eugene A. Pivnev 2021-04-19 08:55:33 UTC
(In reply to Chris Murphy from comment #22)
> The Fedora created grub$ARCH.efi works for their use case perfectly fine
> without requiring grub-install.

Yes. If it is not grub-2.06*.
I checked your receipt yesterday:

```
dnf reinstall grub2 shim-x64
grub2-mkconfig -o /boot/efi/EFI/fedora/grub...
```

This really works, you are right.
If it is grub*-2.04.

Comment 25 Chris Murphy 2021-04-19 21:11:48 UTC
(In reply to Eugene A. Pivnev from comment #24)
> 
> Yes. If it is not grub-2.06*.
> I checked your receipt yesterday:
> 
> ```
> dnf reinstall grub2 shim-x64
> grub2-mkconfig -o /boot/efi/EFI/fedora/grub...
> ```
> 
> This really works, you are right.
> If it is grub*-2.04.

Except you've got the command wrong, that isn't what I wrote in either comment 2 or comment 11. The comment 11 command is more universal, it accounts for other archs, including on x86 where in rare cases the 32-bit bootloaders are needed. And that comment 11 command does correctly reinstall the bootloader if you already have grub 2.06.

Comment 26 Samuel J. Brekke 2021-04-25 03:07:03 UTC
Chris, If it is indeed the case that we don't want to use grub2-install for EFI boot, what is the current recommendation for having multiple installers of Redhat, CentOS and, Fedora on the same USB drive?

Comment 27 Chris Murphy 2021-04-25 03:56:50 UTC
Distros would say one USB stick per installer image. They're not designed to share a flash drive.

But, distro specific bootloaders and configs in their own EFI/ directory, and using the firmware boot manager to choose which distro boots. That'd work reliably whether UEFI Secure Boot is enabled or not. 

I don't see what this use case has to do with grub2-install though. What does a grub2-install grubx64.efi do that Fedora's grubx64.efi can't do. Any modules that aren't in the Fedora grubx64.efi can be loaded by grub.cfg insmod command, and making sure the proper grub2-efi-$ARCH-modules packages is installed, and the modules you need are copied to the distro specific directory/$ARCH/*mod

Comment 28 Zoltan Boszormenyi 2021-04-25 06:38:14 UTC
My use case is that my laptop runs Fedora but I need to create custom installers for Yocto based Linux OSs using the same tar.xz image, extracting them onto differently sized disks either on a USB pendrive or attached via a SATA-to-USB adapter and running grub2-install on them so they can boot when the disk is put back into the target machine.

This use case is broken with Fedora 33 upgrading to grub2 2.06 and will be broken in Fedora 34 unless I rebuild grub2 with this limitation lifted and excluding it from dnf upgrade.

Comment 29 sgtlion 2021-05-26 15:00:32 UTC
Must agree that this has been a major PITA while following instructions to convert my install from Legacy to UEFI per RedHat's own https://www.redhat.com/sysadmin/bios-uefi

Getting all the way to last command then finding that there's no way to actually execute it is a real hair-tearing moment. Forcibly downloaded and installed the 2.04 grub2 modules so I could finish. Is not leaving users' only last option to be unprotecting and uninstall protected packages perhaps even less advisable than following guidelines?

Comment 30 Chris Murphy 2021-05-26 16:26:46 UTC
(In reply to sgtlion from comment #29)
> Must agree that this has been a major PITA while following instructions to
> convert my install from Legacy to UEFI per RedHat's own
> https://www.redhat.com/sysadmin/bios-uefi

Yep, the article is giving bad advice.

>>[root@localhost ~]# grub2-install --target=x86_64-efi /dev/sda
>>Installing for x86_64-efi platform.

This should be 'dnf reinstall shim-* grub2-efi-*'

Advising a clean install, once disabling the CSM, is better advice than asking users to create a non-standard conversion that's inconsistent with a clean install, and cannot support UEFI Secure Boot booting because the resulting bootloader isn't signed, and the first bootloader isn't even installed with the method described in the article.

Comment 31 Aki Ketolainen 2021-05-26 17:16:01 UTC
Chris, What suggestion do you have for people who've used grub2-install to put grub on an USB stick for booting?

I fear this Fedora decision will end up also in RHEL and derivatives. People also use their computers with
secure boot disabled.

Comment 32 Chris Murphy 2021-05-26 20:26:12 UTC
(In reply to Aki Ketolainen from comment #31)
> Chris, What suggestion do you have for people who've used grub2-install to
> put grub on an USB stick for booting?

It's a good point, and this is not a great venue to do back and forth discussion and iteration to come up with a firm recommendation. GRUB sucks for this use case. It might be true systemd-boot is a valid alternative for that use case, but I haven't looked into it enough to say for sure. Nevertheless, here is a draft, assuming the USB stick is mounted at /mnt

mkdir -p /mnt/EFI/BOOT
mkdir /mnt/EFI/fedora
cp /boot/efi/EFI/BOOT/* /mnt/EFI/BOOT/
cp /boot/efi/EFI/fedora/* /mnt/EFI/fedora/

I think it's a separate conversation what to do about the grub.cfg: it's valid to use any Fedora installation ISO's grub.cfg as a template, or hand create one, or you could manually assemble the USB stick in a chroot so that 'grub2-mkconfig' can work correctly. Or maybe we could come up with a generic grub.cfg for this particular use case.

The logic is, the firmware boot manager is chosen at boot time by the user, which enumerates all devices, and if the user chooses the USB stick, the firmware will automatically find and execute EFI/BOOT/BOOTX64.EFI which in turn will find Fedora's prebuilt EFI/fedora/grubx64.efi and associated grub.cfg. This would be much easier if upstream adopted Boot Loader Spec, published a generic grub.cfg, and then all we'd need are drop-in scripts for loader/entries/ or even possible is dynamic discovery of kernels similar to rEFInd. But I'm way off the track because this discussion doesn't progress this bug. It should be brought up on devel@ list.

Comment 33 Zoltan Boszormenyi 2021-05-27 10:03:46 UTC
We have some hardware without EFI and the USB stick used to install a new OS version must do non-EFI BIOS boot as well.
grub2-install from 2.06~rc1-4.fc34 outright refuses to run on my laptop with EFI, even if grub2-install --target=i386-pc is used against the USB pendrive.
I had to remove that single patch from the specfile and rebuild grub to get this functionality back.

Possibly the best way would be to detect the rootfs device and only refuse to run against that.

Or just allow people to shoot themselves in the foot if they choose to do so without being a helicopter parent.
Running stuff as root was always dangerous and you had to read your command twice before pressing Enter.

Comment 34 Chris Murphy 2021-05-27 18:48:28 UTC
(In reply to Zoltan Boszormenyi from comment #33)

> Or just allow people to shoot themselves in the foot if they choose to do so
> without being a helicopter parent.

That metaphor is not indicated. Blatant "hurt me" buttons are bad for users, and clutter up bug reporting for developers - they consume resources. So does confusion resulting from e.g. Fedora's GRUB having so many patches compared to upstream. My suggestion is Fedora ship the pre-built bootloaders without any user space tools by default; and package unpatched upstream GRUB separately for folks to opt into, i.e. not installed by default, and support can be from upstream GRUB.

Comment 35 Zoltan Boszormenyi 2021-05-29 05:51:33 UTC
(In reply to Chris Murphy from comment #34)
> (In reply to Zoltan Boszormenyi from comment #33)
> 
> > Or just allow people to shoot themselves in the foot if they choose to do so
> > without being a helicopter parent.
> 
> That metaphor is not indicated. Blatant "hurt me" buttons are bad for users,
> and clutter up bug reporting for developers - they consume resources. So
> does confusion resulting from e.g. Fedora's GRUB having so many patches
> compared to upstream. My suggestion is Fedora ship the pre-built bootloaders
> without any user space tools by default; and package unpatched upstream GRUB
> separately for folks to opt into, i.e. not installed by default, and support
> can be from upstream GRUB.

Sorry for my abusive language. But taking away functionality is also abusive.

At least the patch should take the grub2-install --force option into account
which GRUB already has.

Perhaps print a more informative message about what to do if you want to fix
your own machine and still allow getting the boot loader on an external disk
for people knowing what they are doing.

Comment 36 Chris Murphy 2021-05-29 21:56:07 UTC
>taking away functionality is also abusive.

Nope, it is a normal cycle of maintaining software, with limited resources. If there's something in upstream GRUB not in Fedora's GRUB, it's very straightforward to build GRUB from source. The definition of abusive is "engaging in or characterized by habitual violence and cruelty" so I just can't take that seriously at all. There's a lot of work to do, GRUB is complicated, we are working to make it more manageable for everyone, and allowing grub2-install to work with --force is being considered. Like I said way up thread, I think grub2-install not working on UEFI systems with Secure Boot disabled is probably a bug. But the reason why it takes so long to fix things is limited resources compared to the complexity of bootloading right now.

>Perhaps print a more informative message about what to do if you want to fix

Good idea. Hard to maintain, especially when it's a downstream patch. We already have too many of those.

Comment 37 Aki Ketolainen 2021-06-02 17:16:24 UTC
As I thought. Now this (patched?) version has landed on EL8 (Oracle EL8.4).

# grub2-install --efi-directory=/boot/efi --boot-directory=/boot/efi/EFI/redhat --target=x86_64-efi
grub2-install: error: this utility cannot be used for EFI platforms because it does not support UEFI Secure Boot.

# rpm -qf $(which grub2-install)
grub2-tools-2.02-99.0.2.el8.x86_64

Please go back with this decision.

Comment 38 Javier Martinez Canillas 2021-06-22 15:59:14 UTC
*** Bug 1948731 has been marked as a duplicate of this bug. ***

Comment 39 Javier Martinez Canillas 2021-06-22 16:04:53 UTC
*** Bug 1948256 has been marked as a duplicate of this bug. ***

Comment 40 paul.barrette 2021-06-24 15:01:36 UTC
I ran through all these comments but in order to build a bootable usb installer, I had to do the following for fedora 33:

https://gresch.io/2019/05/fedora-30-when-grub2-mkconfig-doesnt-work/

sed -i 's/GRUB_ENABLE_BLSCFG=true/GRUB_ENABLE_BLSCFG=false/' /etc/default/grub

#prepare to reinstall grub
mkdir -p /boot/efi/EFI/fedora
dnf reinstall grub2* shim*

# generate the grub.cfg
grub2-mkconfig -o boot/efi/EFI/fedora/grub.cfg

# Note: this should be outputting linuxefi /vmlinuz... it doesn't, so fix it.
sed -i 's/linux\s\/vml/linuxefi \/vml/g' boot/efi/EFI/fedora/grub.cfg

No need to grub2-install.  That is all.

Comment 41 Olivier LAHAYE 2021-08-20 08:17:24 UTC
This grub stuff is really cr*p....

As SystemImager developper, I need to install bootloader after imaging the distrop.

grub2-install was doing the job for all distros. Now I need a switch case per distro for:
- where do I generate the grub.cfg (/boot/efi/EFI/<distroid>/grub.cfg or /boot/grub2/grub.cfg) Any idea of reliable way to check that across ALL distros?
- how do I create EFI boot menu entry, replacing previous entry if it already exists in a relyable way?
- how do I check that correct efi files are available for the computer being installed (ON ALL DISTRO, not fedora centric)?

Linux is lightyears away from MacOS and (sadly) windows regarding those things as simple as a boot loader which should be simpkle to setup and be the same across all distro.
(And I don't even speak about graphic themes when you PXE grub boot from EFI...)

Maybe it's time to replace this needlessly complex stuff (grub) with some more modern stuff using a simple xml/json/plist menu description instead of those needlessly complex pieces of scripts that are assembled.

While you are at it, you can remove the --platform=x86_64-efi That makes no sens to support this platform and says you don't support it when it is used.

Comment 42 Sergio Basto 2021-09-07 14:30:05 UTC
https://fedoraproject.org/wiki/GRUB_2#Instructions_for_BIOS-based_systems 

Do not use the grub2-install command on UEFI systems. On those systems, bootloaders are in the shim and grub-efi RPM packages. By reinstalling those packages, the bootloaders are reinstalled to their proper location in /boot/efi/ on the EFI System volume.

Comment 43 Sergio Basto 2021-09-07 21:11:36 UTC
(In reply to Sergio Basto from comment #42)
> https://fedoraproject.org/wiki/GRUB_2#Instructions_for_BIOS-based_systems 
> 
> Do not use the grub2-install command on UEFI systems. On those systems,
> bootloaders are in the shim and grub-efi RPM packages. By reinstalling those
> packages, the bootloaders are reinstalled to their proper location in
> /boot/efi/ on the EFI System volume.


sorry the most update information now is in docs.fedoraproject.org

https://docs.fedoraproject.org/en-US/fedora/rawhide/system-administrators-guide/kernel-module-driver-configuration/Working_with_the_GRUB_2_Boot_Loader/

Comment 44 Brian J. Murrell 2021-10-07 01:12:06 UTC
How am I supposed to install grub onto a disk image for a bios based machine such as QEMU/KVM/libvirt?

Comment 45 Aleksandr Kwaskoff 2021-11-08 18:04:03 UTC
I have installed fedora 35 on disk with 34 in LUKS, but forgot unencrypt 34, and grub forgot about 34 =(
I had chroot to 34 and grub autorepair it, cool! It found 34 and 35, but after reboot my grub is empty (What?!)
Now I booted to live cd and chroot to 34 again:

[root@localhost-live /]# grub2-install --recheck --no-floppy /dev/nvme0n1p2
grub2-install: error: this utility cannot be used for EFI platforms because it does not support UEFI Secure Boot.

WTF!?

Comment 46 Zirneklitis 2021-12-07 22:19:26 UTC
How am I supposed to install grub onto a flash-disk for EFI-only boot computers?

grub-install-disable-support-for-EFI-platforms.patch creates lot of problems!!!

The only solution was to rebuild grub2 without this patch and reinstall grub2-tools (with official repos disabled).

Comment 47 paul.barrette 2021-12-08 18:48:03 UTC
FYI, you don't need grub2-install for EFI systems, it makes no sense.  

1. Generate the grub.cfg file in the correct place (e.g. /boot/efi/EFI/<DISTRO NAME>)
2. Tell the efi where it is, e.g.

efibootmgr -c -d  /dev/<part>  -p 1 -L <OS name, e.g. centos> -l '\EFI\BOOT/BOOTX64.efi'.

Pb

Comment 48 Sergio Basto 2021-12-08 19:08:45 UTC
(In reply to paul.barrette from comment #47)
> FYI, you don't need grub2-install for EFI systems, it makes no sense.  
> 
> 1. Generate the grub.cfg file in the correct place (e.g.
> /boot/efi/EFI/<DISTRO NAME>)
> 2. Tell the efi where it is, e.g.
> 
> efibootmgr -c -d  /dev/<part>  -p 1 -L <OS name, e.g. centos> -l
> '\EFI\BOOT/BOOTX64.efi'.
> 
> Pb

let's add this message instead " error: this utility cannot be used for EFI platforms because it does not support UEFI Secure Boot. "

Comment 49 Valdis Kletnieks 2021-12-08 20:33:40 UTC
(In reply to Sergio Basto from comment #48)
> let's add this message instead " error: this utility cannot be used for EFI
> platforms because it does not support UEFI Secure Boot. "

Only problem with that is that is the exact message that I was getting that started off
this whole bug report..

Comment 50 Zoltan Boszormenyi 2021-12-10 06:11:50 UTC
So, what would you suggest using instead of this command
if I want to create a USB disk bootable on legacy systems?

grub2-install --boot-directory=/mnt/boot --target=i386-pc /dev/sdb

Because this command also doesn't run if I want to create
the USB bootable disk on an EFI system with Fedora.

FYI I need to create hybrid bootable disks with both EFI and
BIOS boot partitions so the same stick is usable one either.

The only solution for now is to remove or revert the patch
and rebuild grub2 on Fedora for my needs.

Comment 51 Sergio Basto 2021-12-11 04:39:45 UTC
(In reply to Zoltan Boszormenyi from comment #50)
> So, what would you suggest using instead of this command
> if I want to create a USB disk bootable on legacy systems?
> 
> grub2-install --boot-directory=/mnt/boot --target=i386-pc /dev/sdb

the replacement seems that is efibootmgr [1] , isn't it ? 

sou message of grub2-install should say  "this utility cannot be used for EFI platforms, please use efibootmgr instead"

[1]
efibootmgr -c -d  /dev/<part>  -p 1 -L <OS name, e.g. centos> -l '\EFI\BOOT/BOOTX64.efi'.

Comment 52 Zoltan Boszormenyi 2021-12-11 08:03:26 UTC
(In reply to Sergio Basto from comment #51)
> (In reply to Zoltan Boszormenyi from comment #50)
> > So, what would you suggest using instead of this command
> > if I want to create a USB disk bootable on legacy systems?
> > 
> > grub2-install --boot-directory=/mnt/boot --target=i386-pc /dev/sdb
> 
> the replacement seems that is efibootmgr [1] , isn't it ? 

You seem to have not read the command fully. --target=i386-pc doesn't
have anything to do with EFI, it's the legacy MBR boot.

grub2-install IF RUN ON AN EFI SYSTEM prevents creating an
MBR boot manager on an external disk that I would put into
a different machine. That's a bug.

I argue that it's a bug to disallow creating ANY boot manager
(including EFI) ON AN EXTERNAL DISK if running on an EFI system.

There's a way to detect whether the target disk for grub2-install
is the primary boot disk in the machine and only refuse to
reinstall the boot manager on that. Other disks should be allowed.

> sou message of grub2-install should say  "this utility cannot be used for
> EFI platforms, please use efibootmgr instead"
> 
> [1]
> efibootmgr -c -d  /dev/<part>  -p 1 -L <OS name, e.g. centos> -l
> '\EFI\BOOT/BOOTX64.efi'.

Comment 53 Sergio Basto 2021-12-11 20:49:12 UTC
(In reply to Zoltan Boszormenyi from comment #52)
> (In reply to Sergio Basto from comment #51)
> > (In reply to Zoltan Boszormenyi from comment #50)
> > > So, what would you suggest using instead of this command
> > > if I want to create a USB disk bootable on legacy systems?
> > > 
> > > grub2-install --boot-directory=/mnt/boot --target=i386-pc /dev/sdb
> > 
> > the replacement seems that is efibootmgr [1] , isn't it ? 
> 
> You seem to have not read the command fully. --target=i386-pc doesn't
> have anything to do with EFI, it's the legacy MBR boot.
> 
> grub2-install IF RUN ON AN EFI SYSTEM prevents creating an
> MBR boot manager on an external disk that I would put into
> a different machine. That's a bug.
> 
> I argue that it's a bug to disallow creating ANY boot manager
> (including EFI) ON AN EXTERNAL DISK if running on an EFI system.
> 
> There's a way to detect whether the target disk for grub2-install
> is the primary boot disk in the machine and only refuse to
> reinstall the boot manager on that. Other disks should be allowed.

OK , right , I see , thanks for this resume . 
I was focused in the message for primary boot disk ...

Comment 54 Chris Murphy 2021-12-13 19:40:45 UTC
The problem to solve is: on UEFI, grub2-install results in the Fedora signed grub$arch.efi file being silently replaced with a non-signed version (that also has rather different behaviors than the signed one) resulting in user confusion and boot failure when Secure Boot is enabled

In order to properly install the bootloader on UEFI:
a. An RPM -V verified copy of grub$arch.efi needs to be in /usr/lib/grub
b. Copy /usr/lib/grub/grub$arch.efi and /usr/lib/grub/$arch modules (if present) to the user specified destination; or to /boot/efi/EFI/fedora if not specified

@rharwood any opinion on doing this instead of --force? And then also reverting the "grub2-install: error: this utility cannot be used for EFI platforms because it does not support UEFI Secure Boot" patch?

Comment 55 Vincent S. Cojot 2021-12-13 21:28:32 UTC
Hi everyone,

I got the article updated to mention 'dnf reinstall'.
I am not up to date on the current state of patches in downstream grub but I am not too fond of replacing
'grub2-install'
with
'dnf reinstall grub2* shim*'

I think the functionality of running the migration from BIOS to UEFI (or whatever other reason) in an offline/disconnected environment is something that would be handy to keep along.

'grub2-install' is an offline local command which can be executed without a working network or if the fedora update servers are not available...

'dnf reinstall', on the contrary requires a working network connection that lets you reach out to the Fedora update servers (not all coporate proxies allow that, even if you have a working network).

This is my 2c but like I said I am mostly unaware of the challenges faced by the downstream maintainers of GRUB.

Comment 56 Julian Ospald 2022-01-05 03:19:01 UTC
I just stumbled over this bug while trying to rescue my laptop after a hardware repair. Instead I have to read through this entire thread and still don't really know what to do. I wish I had installed a different live USB. Thanks for wasting our time with downstream patches.

Comment 57 Andrew 2022-03-29 16:57:38 UTC
Same for me. I managed to break grub somehow and can't find how to get it back.

My PC stills boots, but seems like it uses systemd-boot (that thing from `bootctl install`) and grub is not involved at all (?).
Seems like grub config is ignored, at least.

grub2-install tells same:  "error: this utility cannot be used for EFI platforms because it does not support UEFI Secure Boot."
Secure Boot is disabled for my case.

The approach described above changes nothing:
# dnf reinstall grub2-* shim-*
Same reinstall is described here: https://docs.fedoraproject.org/en-US/fedora/rawhide/system-administrators-guide/kernel-module-driver-configuration/Working_with_the_GRUB_2_Boot_Loader/

Seems like correct result, because there are no install scripts at all for these packages:
$ rpm -q --scripts --triggers `rpm -qa 'grub2*efi*' shim'*'`

And install scripts of grub2* seem to deal with config mostly:

$ rpm -q --scripts --triggers `rpm -qa 'grub2*'`

    posttrans scriptlet (using /bin/sh):
    set -eu

    EFI_HOME=/boot/efi/EFI/fedora
    GRUB_HOME=/boot/grub2
    ESP_PATH=/boot/efi

    if ! mountpoint -q ${ESP_PATH}; then
        exit 0 # no ESP mounted, nothing to do
    fi

    if test ! -f ${EFI_HOME}/grub.cfg; then
        # there's no config in ESP, create one
        grub2-mkconfig -o ${EFI_HOME}/grub.cfg
    fi

    if grep -q "configfile" ${EFI_HOME}/grub.cfg; then
        exit 0 # already unified, nothing to do
    fi

    # create a stub grub2 config in EFI
    BOOT_UUID=$(grub2-probe --target=fs_uuid ${GRUB_HOME})
    GRUB_DIR=$(grub2-mkrelpath ${GRUB_HOME})

    cat << EOF > ${EFI_HOME}/grub.cfg.stb
    search --no-floppy --fs-uuid --set=dev ${BOOT_UUID}
    set prefix=(\$dev)${GRUB_DIR}
    export \$prefix
    configfile \$prefix/grub.cfg
    EOF

    if test -f ${EFI_HOME}/grubenv; then
        cp -a ${EFI_HOME}/grubenv ${EFI_HOME}/grubenv.rpmsave
        mv --force ${EFI_HOME}/grubenv ${GRUB_HOME}/grubenv
    fi

    cp -a ${EFI_HOME}/grub.cfg ${EFI_HOME}/grub.cfg.rpmsave
    cp -a ${EFI_HOME}/grub.cfg ${GRUB_HOME}/
    mv ${EFI_HOME}/grub.cfg.stb ${EFI_HOME}/grub.cfg
    preinstall scriptlet (using /bin/sh):
    if [ -f /boot/grub2/user.cfg ]; then
        if grep -q '^GRUB_PASSWORD=' /boot/grub2/user.cfg ; then
            sed -i 's/^GRUB_PASSWORD=/GRUB2_PASSWORD=/' /boot/grub2/user.cfg
        fi
    elif [ -f /boot/efi/EFI/fedora/user.cfg ]; then
        if grep -q '^GRUB_PASSWORD=' /boot/efi/EFI/fedora/user.cfg ; then
            sed -i 's/^GRUB_PASSWORD=/GRUB2_PASSWORD=/' \
                /boot/efi/EFI/fedora/user.cfg
        fi
    elif [ -f /etc/grub.d/01_users ] && \
            grep -q '^password_pbkdf2 root' /etc/grub.d/01_users ; then
        if [ -f /boot/efi/EFI/fedora/grub.cfg ]; then
            # on EFI we don't get permissions on the file, but
            # the directory is protected.
            grep '^password_pbkdf2 root' /etc/grub.d/01_users | \
                    sed 's/^password_pbkdf2 root \(.*\)$/GRUB2_PASSWORD=\1/' \
                > /boot/efi/EFI/fedora/user.cfg
        fi
        if [ -f /boot/grub2/grub.cfg ]; then
            install -m 0600 /dev/null /boot/grub2/user.cfg
            chmod 0600 /boot/grub2/user.cfg
            grep '^password_pbkdf2 root' /etc/grub.d/01_users | \
                    sed 's/^password_pbkdf2 root \(.*\)$/GRUB2_PASSWORD=\1/' \
                > /boot/grub2/user.cfg
        fi
    fi

SW versions:
    $ rpm -qa 'grub2*' shim'*'
    grub2-common-2.06-29.fc36.noarch
    grub2-tools-minimal-2.06-29.fc36.x86_64
    grub2-tools-2.06-29.fc36.x86_64
    grub2-efi-x64-2.06-29.fc36.x86_64
    grub2-pc-modules-2.06-29.fc36.noarch
    grub2-pc-2.06-29.fc36.x86_64
    shim-x64-15.4-5.x86_64
    grub2-tools-extra-2.06-29.fc36.x86_64
    grub2-efi-x64-modules-2.06-29.fc36.noarch
    grub2-tools-efi-2.06-29.fc36.x86_64

Comment 58 Chris Murphy 2022-03-31 20:28:47 UTC
You probably need to use efibootmgr --bootorder to change the bootorder. I imagine it's still using sd-boot. efibootmgr -v will provide path to bootloader info for all the entries. If none of them point to the correct device+partition+path to shim or grub, then you can try just deleting all the boot entries with paths to a bootloader, and in theory the firmware will find the default bootloader which should be shim. Shim will detect whether there's an entry for it in NVRAM and if not, add one.

Comment 59 Andrew 2022-04-03 13:10:40 UTC
Thank you, `efibootmgr -v` was really helpful!
Firmware was able to find grub after deletion another boot entries.
Seems like main problem for my case is ESP mount point: I have it on /efi as `man bootctl` recommends, but grub expects it here as listed above: ESP_PATH=/boot/efi

I changed it to /boot/efi, but seems like some things are still out of sync.
My /boot is on the same partition with /, and reinstalling grub packages creates empty /boot/loader/entries dir - while my real path is (ESP)/loader/entries.
This (?) results in grub menu containing only "boot to firmware" entry, without my real Linux kernels.

Besides all of that, I see that grub config is separated now: small (ESP)/EFI/fedora/grub.cfg includes big /boot/grub2/grub.cfg
Is the correct layout described anywhere (except `man bootctl`)? I mean recommended mount points of Extended Boot Loader partition and EFI System Partition.
I don't see it here as well: https://docs.fedoraproject.org/en-US/fedora/rawhide/system-administrators-guide/kernel-module-driver-configuration/Working_with_the_GRUB_2_Boot_Loader/

Comment 60 Chris Murphy 2022-04-05 15:55:15 UTC
Some of the changes from upstream GRUB are described here:
https://fedoraproject.org/wiki/Changes/UnifyGrubConfig
https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault

bootctl is systemd-boot which is a completely unrelated bootloader, doesn't have anything to do with GRUB, and at the moment isn't supported in Fedora (but is supported by systemd upstream)

Most all cases are fixed by following: https://fedoraproject.org/wiki/GRUB_2#Instructions_for_UEFI-based_systems
If that doesn't work, you might need to reinstall a kernel package, which is what creates the drop-in snippets found in /boot/loader/entries

Comment 61 Ben Cotton 2022-05-12 16:23:42 UTC
This message is a reminder that Fedora Linux 34 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '34'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 34 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.


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