Bug 1917213

This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle.
Changing version to 34.

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 \.

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

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.

Why do you need grub2-install on EFI ? To create the EFI boot entry ?

(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.

(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.

Fedora 33 at MacBook mid 2012 - same problem.
After today's dnf update

@ti.eugene 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.

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`.

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.

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.

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.

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 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.

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.

(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.

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.

(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.

(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.

(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.

(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.

Now grub2-install fails even when running against a USB pendrive with --removable.
That should be possible to do.

(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.

(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.

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?

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

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.

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?

(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.

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.

(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.

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.

(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.

(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.

>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.

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.

*** Bug 1948731 has been marked as a duplicate of this bug. ***

*** Bug 1948256 has been marked as a duplicate of this bug. ***

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.

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.

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.

(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/

How am I supposed to install grub onto a disk image for a bios based machine such as QEMU/KVM/libvirt?

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!?

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).

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

(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. "

(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..

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.

(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'.

(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'.

(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 ...

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?

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.

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.

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

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.

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/

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

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.

Hi guys - I'm wondering if anyone could let me know the equivilent command using efibootmgr now thhat grub2-install doesn't work.  Here is my current command being called from a python script (Citrix pvs-imager)

grub2-install --debug --force --efi-directory=/tmp/Volumes.py-dd2snrj7/boot/efi --target=x86_64-efi--boot-directory=/tmp/Volumes.py-dd2snrj7/boot /dev/loop0

I believe the script is modifying the bootloader in preparation for tasking a master image for PVS.

This is on RHEL 8.6 using EFI with secure boot enabled.

Any help would be greatly appreciated.

Strictly speaking efibootmgr isn't needed because lacking any NVRAM entry, or the firmware not finding a bootloader with an existing NVRAM entry, the firmware will find the shim bootloader in the fallback location, and the shim bootloader will add a proper NVRAM entry.

All you need to do is assemble the image per fstab, chroot, then
# dnf reinstall shim-* grub2-efi-* grub2-common

This will install the signed bootloader binaries, which grub2-install cannot provide, and runs a script that generates the proper grub.cfg and BLS drop-in snippets.

(In reply to Chris Murphy from comment #63)
> All you need to do is assemble the image per fstab, chroot, then
> # dnf reinstall shim-* grub2-efi-* grub2-common

You don't pay attention to the explicitly quoted use cases.

None of the packages you listed helps installing the boot loader
on devices that are NOT the host's boot disk, e.g. /dev/loop0
and hotplugged devices.

And the most infuriating detail is that grub2-install refuses
to work if the host is EFI but I want the target device to use
--target=i386-pc

Please refer to the answer to my previous tirade that admits
that the complaint is justified.
https://bugzilla.redhat.com/show_bug.cgi?id=1917213#c53

@

(In reply to Valdis Kletnieks from comment #0)

Please bump the Fedora version in the ticket as it is still a problem in Fedora 36.

(In reply to Zoltan Boszormenyi from comment #64)
> You don't pay attention to the explicitly quoted use cases.

I was responding only to comment 62.

>And the most infuriating detail is that grub2-install refuses to work if the host is EFI but I want the target device to use --target=i386-pc

A valid option is to build GRUB locally, either upstream git, or Fedora source removing this patch https://src.fedoraproject.org/rpms/grub2/blob/rawhide/f/0148-grub-install-disable-support-for-EFI-platforms.patch

I've asked GRUB developers about alternatives, including only refusing to overwrite an existing bootloader in ESP//EFI/BOOT/ or ESP//EFI/fedora/ without a --force flag. The main idea of the patch inhibiting grub2-install on EFI is to avoid the inadvertent case of users stepping on the provided signed bootloader, thereby rendering their system unbootable. But it should be OK to permit a new installation of a custom/unsigned bootloader without inhibition. But we need to think about how any changes will confuse users. The current and previous behaviors are unsatisfactory so before there's another change, we need to imagine how it might make things worse.

(In reply to Chris Murphy from comment #67)
> (In reply to Zoltan Boszormenyi from comment #64)
> > You don't pay attention to the explicitly quoted use cases.
> 
> I was responding only to comment 62.
> 
> >And the most infuriating detail is that grub2-install refuses to work if the host is EFI but I want the target device to use --target=i386-pc
> 
> A valid option is to build GRUB locally, either upstream git, or Fedora
> source removing this patch
> https://src.fedoraproject.org/rpms/grub2/blob/rawhide/f/0148-grub-install-
> disable-support-for-EFI-platforms.patch
> 
> I've asked GRUB developers about alternatives, including only refusing to
> overwrite an existing bootloader in ESP//EFI/BOOT/ or ESP//EFI/fedora/
> without a --force flag. The main idea of the patch inhibiting grub2-install
> on EFI is to avoid the inadvertent case of users stepping on the provided
> signed bootloader, thereby rendering their system unbootable.

Which is indeed a valid concern.

> But it should
> be OK to permit a new installation of a custom/unsigned bootloader without
> inhibition. But we need to think about how any changes will confuse users.
> The current and previous behaviors are unsatisfactory so before there's
> another change, we need to imagine how it might make things worse.

I think the easiest way is to expect the user to explicitly
specify a device.

By default (no device name specified) grub2-install targets the host's
boot device and this is what may is usually and accidentally omitted.
Users can indeed shoot themselves in the foot that way.

If the explicit device name would be the prohibiting factor (perhaps
coupled with a different warning to the effect of "use the signed boot
loader instead of grub2-install - run dnf blahblah") then
* users would think twice
* it would allow using grub2-install on the device the user wanted

For people in the same boat: these are the steps that made it work for me:
- sudo dnf reinstall grub2-efi-x64 shim-x64
- sudo dnf install grub2-efi-x64 shim-x64 <- of previous command failed
- efibootmgr -c -d  /dev/sda -p 1 -L "Fedora" -l '\EFI\fedora\grubx64.efi'

To @Peter Jones and/or other Fedora/Redhat developers:
This is quite frustrating. I was pulling my hair for more than a day to fix this issue which never had before. Please allow a "--force" option for grub2-install!

I've just fallen in the the very same issue on Fedora 36
while trying to create hybrid UEFI GPT and BIOS GPT/MBR
multiboot USB flash drive in order to boot misc. ISO
images.

I think it is quite natural to do it this way and wear
just one flash drive in pocket instead of many. (Well,
my actual use case is slighly different but you may
understand.)

AFAIK the only option for us to achieve what some of us
would like to is still to rebuild GRUB2 package without
the patch? Is that correct?

I understood you are NOT going to revert the patch. Then
provide us at least with some workarounds based on what
people stated they need in this very thread, please.
There are interesting use cases that are now disallowed!

Thank you,

-- 
mjf

mjf: I was in your shoes in 2021 https://bugzilla.redhat.com/show_bug.cgi?id=1917213#c31

I just finished writing up how I copied the contents of the Ubuntu ISO image to a USB stick and then booting it in UEFI mode (no secure boot).
It starts \EFI\boot\grubx64.efi and then reads the grub.cfg from the USB stick and then boots up the Ubuntu installer. I hope this helps you in figuring
out how to use grub on Fedora for your use case.

Here's the modified part of the grub.cfg:

menuentry "Try or Install Ubuntu" {
        insmod part_gpt
        insmod fat
        search --fs-uuid --set usb_esp --no-floppy 921A-DA9A   # from blkid /dev/sdb1
        set gfxpayload=keep
        linux   ($usb_esp)/casper/vmlinuz
        initrd  ($usb_esp)/casper/initrd
}

Here's the guide: https://atkdinosaurus.wordpress.com/2023/03/31/how-to-transfer-the-contents-of-the-ubuntu-iso-installer-to-a-usb-stick/

Aki

> It starts \EFI\boot\grubx64.efi

I actually think the computer is loading \EFI\boot\bootx64.efi instead. I read some days ago that it would
be a "default" UEFI boot file. Running efibootmgr when booted off a normal setup (from HDD/SSD), modifies that computers UEFI,
and probably does nothing for the USB stick.

I confirmed this by "mv /mnt/usb_esp/EFI/boot/bootx64.efi /mnt/usb_esp/EFI/boot/bootx64.efi_" The computer failed booting the same USB stick that booted previously.

I wrote the same guide for Fedora (how to copy the iso contents to a usb stick (efi esp as fat32 and / as ext4):

https://atkdinosaurus.wordpress.com/2023/04/03/how-to-transfer-the-contents-of-the-fedora-iso-installer-to-a-usb-stick/

That still doesn't help if I want to create a hybrid installer
to use on legacy BIOS / CSM-enabled machines and want to run
this command on an EFI system:

grub2-install --target=i386-pc /dev/sdb

The EFI system partition has nothing to do with booting
on legacy BIOS machines.

> grub2-install --target=i386-pc /dev/sdb

Is that broken now too?

Zoltan Boszormenyi: I wrote this earlier for having both BIOS and UEFI boot possibility on one USB stick:

https://atkdinosaurus.wordpress.com/2021/05/15/how-to-boot-a-fedora-33-usb-stick-in-both-bios-and-uefi-modes/

I haven't tested it in a while but it worked in 2021 with Fedora 33.

(In reply to Aki Ketolainen from comment #76)
> > grub2-install --target=i386-pc /dev/sdb
> 
> Is that broken now too?

Yes, it is.

(In reply to Aki Ketolainen from comment #77)
> Zoltan Boszormenyi: I wrote this earlier for having both BIOS and UEFI boot
> possibility on one USB stick:
> 
> https://atkdinosaurus.wordpress.com/2021/05/15/how-to-boot-a-fedora-33-usb-
> stick-in-both-bios-and-uefi-modes/
> 
> I haven't tested it in a while but it worked in 2021 with Fedora 33.

This started in Fedora 34 from the version reported in #0

Zoltan Boszormenyi: I was able to create the F37 usb stick so that it boots in both BIOS and UEFI modes.
Initially I had problems figuring this out, but it ended up being my Acer F5-572g laptop that was not working. 
On an ASUS tower PC (BIOS mode) and on a Dell Precision M 4700 (UEFI mode) there were no problems.
The UEFI mode installation was done in non-secure boot mode.

---

prepare installation target usb stick:

# lsblk -o +TRAN | grep -i usb
sdc      8:32   1 119.5G  0 disk                  usb

(umount all filesystems that are mounted off the installation target usb stick) 
# grep sdc /proc/mounts
# umount /media/username/mount

(erase the first 1GiB of the usb stick just in case)
# dd if=/dev/zero of=/dev/sdc bs=1M count=1024 status=progress

(needed after dd)
# sgdisk -Z /dev/sdc

(create partitions on the usb stick)
# sgdisk \
--new 1:0:+128M  --typecode=1:ef02 --change-name=1:'BIOS boot' \
--new 2:0:+1024M --typecode=2:ef00 --change-name=2:'EFI System' \
--new 3:0:-0     --typecode=3:8300 --change-name=3:'Linux filesystem' \
/dev/sdc

# parted -s /dev/sdc print
Model: Kingston DataTraveler G3 (scsi)
Disk /dev/sdc: 16.1GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name              Flags
 1      1049kB  135MB   134MB                BIOS boot         bios_grub
 2      135MB   1209MB  1074MB               EFI System        boot, esp
 3      1209MB  16.1GB  14.8GB               Linux filesystem

(format usb stick bios boot)
# mkfs.msdos /dev/sdc1

(format usb stick esp)
# mkfs.vfat /dev/sdc2

boot the computer that you're using for the installation with two usb sticks connected.
one has the f37 installer iso, the other is the installation target.

(in f37 live session before the install, see the installation target usb stick)
# lsblk -o +TRAN | grep -i usb
sdb      8:32   1 119.5G  0 disk                  usb

(umount all filesystems that are mounted off the installation target usb stick) 
# grep sdb /proc/mounts
# umount /media/username/mount

start the installer

when you get to the disk selection, choose advanced custom (blivet-gui)

set usb stick esp (/dev/sdb2) mount point to /boot/efi
format usb stick ext4 root fs (/dev/sdb3) and set its mount point to /

after installation the usb stick wouldn't boot on my acer-f5-f572g laptop
until i added the file grubx64.efi as an uefi bootable file in the laptop's
uefi menus. i changed the boot mode from uefi to legacy, but the stick 
wouldn't boot on the acer-f5-572g in legacy mode. it booted fine 
on the dell precision m 4700 in uefi mode and on an ASUS tower pc (BIOS mode).

after booting up the usb stick fedora 37 in uefi mode, enable the BIOS mode boot
onto the USB stick:

# lsblk -o +TRAN | grep -i usb
sdb      8:16   1  14.9G  0 disk             usb

# grub2-install --target=i386-pc --boot-directory=/boot /dev/sdb
Installing for i386-pc platform.
Installation finished. No error reported.

# grub2-mkconfig -o /boot/grub2/grub.cfg 
Generating grub configuration file ...
Found Ubuntu 22.04.2 LTS (22.04) on /dev/sda2   # <- this is on the dell precision m 4700 ssd
Adding boot menu entry for UEFI Firmware Settings ...
done

I'd just like to +1 the sentiments by previous comments that this has broken the legitimate use case of installing GRUB from a Fedora host into a virtual machine image through a loop device for me.

I understand the original motivation of the patch. Trying to prevent people from bricking their installations is certainly a valid and commendable goal. But the heavy-handed approach of just bricking the program completely without any way to override and little consideration for other use cases, and to then leave it broken for years is just a really poor showing that makes me ponder the overall quality of Red Hat's downstream patches.

Here's how you can create a Fedora 37 BIOS/UEFI bootable USB stick from within Fedora 37:

sudo -i

cd /var/tmp

lsblk -o +TRAN | grep usb
sdb

wipefs -a /dev/sdb

sgdisk -Z /dev/sdb

sgdisk \
--new 1::+256M  --typecode=1:ef02 --change-name=1:'BIOS boot' \
--new 2::+1024M --typecode=2:ef00 --change-name=2:'EFI System' \
--new 3::-0     --typecode=3:8300 --change-name=3:'Linux filesystem' \
/dev/sdb

parted /dev/sdb print

mkfs.vfat /dev/sdb2

mkfs.ext4 -F -b 4096 /dev/sdb3

mkdir -p /var/tmp/fedora37

mount /dev/sdb3 /var/tmp/fedora37

mkdir -p /var/tmp/fedora37/boot/efi

mount /dev/sdb2 /var/tmp/fedora37/boot/efi

for i in /proc /sys /sys/fs/selinux /dev /dev/pts
do
    mkdir -p /var/tmp/fedora37${i}
    mount --bind ${i} /var/tmp/fedora37${i}
done

dnf --installroot=/var/tmp/fedora37 --releasever=37 --repo=fedora --repo=fedora-modular --repo=updates --repo=updates-modular install -y dnf systemd openssh-clients openssh-server passwd vim mc lftp util-linux parted gdisk iputils iproute nmap-ncat bind-utils grub2-common grub2-pc-modules grub2-tools-minimal grub2-tools grub2-efi-ia32 grub2-efi-x64 grub2-pc grub2-tools-extra grub2-tools-efi shim-x64 kernel-modules-core kernel-core kernel-modules kernel kernel-modules-extra kernel-devel dracut btrfs-progs vim-minimal less NetworkManager NetworkManager-wifi dhcp-client policycoreutils libsemanage selinux-policy audit

chroot /var/tmp/fedora37 /bin/bash

passwd root

blkid /dev/sdb3 > /etc/fstab
blkid /dev/sdb2 >> /etc/fstab

/etc/fstab:

UUID=EAF3-0160                            /boot/efi vfat umask=0077,shortname=winnt 0 1
UUID=d163d3a0-fc60-4491-afde-8cefe3f1c011 /         ext4 defaults,noatime,nodiratime 0 2

mv /boot/efi/EFI/fedora/grub.cfg /boot/efi/EFI/fedora/grubx64.efi /boot/efi/EFI/BOOT

rm -rf /boot/efi/EFI/fedora

add net.ifnames=0 to both /etc/default/grub and /etc/kernel/cmdline

GRUB_TIMEOUT="5"
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT="saved"
GRUB_DISABLE_SUBMENU="true"
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="net.ifnames=0"
GRUB_DISABLE_RECOVERY="true"
GRUB_ENABLE_BLSCFG="true"

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

exit

umount -R /var/tmp/fedora37

after an uefi boot, setup the BIOS mode boot for /dev/sdb:

sudo -i

lsblk -o +TRAN | grep usb
sdb

grub2-install --target=i386-pc --boot-directory=/boot /dev/sdb
grub2-mkconfig -o /boot/grub2/grub.cfg

(In reply to Aki Ketolainen from comment #81)
> Here's how you can create a *Fedora* 37 BIOS/UEFI bootable USB stick from
> within Fedora 37:

For many use cases, this is not relevant.

The disk may contain a different Linux distro build, not Fedora.
For one, I have a minimal bzImage + initramfs build based on Yocto.

Partitioning and formatting the partitions are okay but I still need
grub2-install to work on the target disk because the EFI boot file
won't be Fedora's.

> For many use cases, this is not relevant.

I don't understand what you mean. How is a guide written to be used on Fedora not relevant? This is Red Hat's bug tracker for Fedora. I don't even know what Yocto is. It seems now obvious that Fedora is not fixing this issue with grub2-install in non-secure boot setups.

For one, why is this needed?
=======================================
dnf --installroot=/var/tmp/fedora37 --releasever=37 --repo=fedora --repo=fedora-modular --repo=updates --repo=updates-modular install -y dnf systemd openssh-clients openssh-server passwd vim mc lftp util-linux parted gdisk iputils iproute nmap-ncat bind-utils grub2-common grub2-pc-modules grub2-tools-minimal grub2-tools grub2-efi-ia32 grub2-efi-x64 grub2-pc grub2-tools-extra grub2-tools-efi shim-x64 kernel-modules-core kernel-core kernel-modules kernel kernel-modules-extra kernel-devel dracut btrfs-progs vim-minimal less NetworkManager NetworkManager-wifi dhcp-client policycoreutils libsemanage selinux-policy audit
=======================================

In my case there should be no pieces of Fedora on the target disk,
including the RPM database.

Remember, I don't intend to create a *Fedora boot disk*.

My use case is to create a boot disk for a different system,
in this case an embedded Yocto based distro image.
The distro image has everything, except the boot loader.

I am used to use Fedora, and the feature to create a generic
boot disk using GRUB was part of my workflow.

> For one, why is this needed?
> =======================================
> dnf --installroot=/var/tmp/fedora37

It installs Fedora 37 into /var/tmp/fedora37

FEDORA-2023-4d409dcff3 has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-4d409dcff3

FEDORA-2023-2a9508cf8d has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-2a9508cf8d

FEDORA-2023-2a9508cf8d has been pushed to the Fedora 38 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-2a9508cf8d`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-2a9508cf8d

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2023-4d409dcff3 has been pushed to the Fedora 39 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-4d409dcff3`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-4d409dcff3

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

What does this even mean?

https://bodhi.fedoraproject.org/updates/FEDORA-2023-4d409dcff3

Mon Nov 6 2023 Nicolas Frayer nfrayer - 2.06-106
util: grub-install on EFI if forced
Resolves: #1917213

(In reply to Aki Ketolainen from comment #90)
> What does this even mean?
> 
> https://bodhi.fedoraproject.org/updates/FEDORA-2023-4d409dcff3
> 
> Mon Nov 6 2023 Nicolas Frayer nfrayer - 2.06-106
> util: grub-install on EFI if forced
> Resolves: #1917213

You have to use option --force from now on.

This should work. Whoever made this change: Thank you!

Zoltan Boszormenyi: I mean the description for the fix is vague as EFI with secure boot and grub2-install worked just fine. EFI without secure boot and grub2-install didn't work.

FEDORA-2023-4d409dcff3 has been pushed to the Fedora 39 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2023-2a9508cf8d has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.

This problem still exists in EL9.3 (Rocky Linux 9.3):

grub2-tools-2.06-70.el9_3.2.rocky.0.2.x86_64 (contains /sbin/grub2-install)

(In reply to Aki Ketolainen from comment #95)
> This problem still exists in EL9.3 (Rocky Linux 9.3):
> 
> grub2-tools-2.06-70.el9_3.2.rocky.0.2.x86_64 (contains /sbin/grub2-install)

A backport for this fix to RHEL 9 is being tracked at https://issues.redhat.com/browse/RHEL-20443.

It currently blocks Hetzner from adopting RHEL 9 (and its derivatives), so hopefully it will be fixed in the near future.

Kleis Auke Wolthuizen: Looks like RHEL-20443 isn't getting any traction. Strange as the fix is already in Fedora.

(In reply to Aki Ketolainen from comment #97)
> Looks like RHEL-20443 isn't getting any traction.

RHEL-20443 is now fixed via commit https://gitlab.com/redhat/centos-stream/rpms/grub2/-/commit/6c0546793ae19d7a217cd7add5b7a493bfad41a6. IIUC, it should become available in the upcoming RHEL 9.4.0 release.