Should /boot/efi/EFI/BOOT/BOOTX64.efi exist on R4.2.1?

Can I get somebody on R4.2.1 (who hasn’t been tinkering with /boot/efi/EFI/BOOT to fix boot issues like I have) to check if this file exists on their install?

Given I had to create it manually to get R4.1.1 to work on my machine, it was my impression it wasn’t an official part of the OS, and thus my sole responsibility to keep up to date. I thought I had deleted it when I found an alternative but after updating to R4.2.1, lo and behold, its back from the dead.

I’m concerned that I didn’t delete it after all and I need to keep manually managing BOOTX64.efi’s updates.

Yes, it was added recently:

# dnf provides /boot/efi/EFI/BOOT/BOOTX64.EFI 
grub2-efi-x64-1000:2.06-3.fc37.x86_64 : GRUB for EFI systems.
Repo        : @System
Matched from:
Filename    : /boot/efi/EFI/BOOT/BOOTX64.EFI

Awesome! Thanks @apparatus, that’s a relief. (It also explains why R4.2.1 fixed my boot woes.)

… Now if only I hadn’t deleted BOOTX64.efi like an idiot yesterday :flushed:

Do you know a good way I can get dnf to redownload it?

For instance would

dnf install package grub2-efi-x64-1000:2.06-3.fc37.x86_64

Be a safe bet for repairing my moment of insanity yesterday.

You can try this:

sudo qubes-dom0-update --action=reinstall grub2-efi-x64
1 Like

Sadly that doesn’t work, I get:

Fedora 37 - x86_64                              5.3 MB/s |  82 MB     00:15    
Fedora 37 - x86_64 - Updates                    5.3 MB/s |  41 MB     00:07    
Qubes Host Repository (updates)                 1.1 MB/s | 1.8 MB     00:01    
Last metadata expiration check: 0:00:01 ago on Sun Apr  7 14:10:48 2024.
Installed package grub2-efi-x64-1000:2.06-3.fc37.x86_64 not available.
Error: No packages marked for reinstall.

Which is odd.

Try with --enablerepo=qubes-dom0-current-testing

(The latest Grub version is included in the R4.2.1 installer, but on the servers it hasn’t been uploaded to the stable repo yet. @marmarek)

1 Like

It’s back, that did it! Thanks @rustybird!

It seems kinda weird that my inplace upgrade ended up with that file the first time round, also thinking about it my inplace upgrade went straight to R4.2.1 instead of R4.2.0 before R4.2.1 was officially announced as released… At the time I just assumed there was a few days lag between the release and the announcement, but maybe my inplace upgrade just generally targeted the testing repo, which is disconcerting.

1 Like

Looks like that’s normal for qubes-dist-upgrade:

Huh, that’s weird given in-place upgrades aren’t really advertised as a tester-only solution. Oh well, I’m sure the Qubes Team know what they’re doing. Presumably there’s nothing to worry about my side and the main repo will eventually get up to speed with everything that’s on my computer.

I’ll probably move over to fresh installs by 4.3 anyway, should finally have comprehensive batch scripts configured for setting up all my fedora templates by then.

Thanks for your help everyone!

1 Like