Bug 1917213 - grub2-install fails, complains about secure boot.
Summary: 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:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-01-18 03:24 UTC by Valdis Kletnieks
Modified: 2021-04-25 06:38 UTC (History)
15 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.


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