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

Fom · April 7, 2024, 12:07pm

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.

apparatus · April 7, 2024, 12:13pm

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

github.com/QubesOS/qubes-issues

Fall back to UEFI shell if Qubes boot entry is missing

opened 09:26AM - 02 Jun 22 UTC

closed 03:55AM - 12 Mar 24 UTC

mehrexe

T: enhancement P: default pr submitted r4.2-host-cur-test C: boot

[How to file a helpful issue](https://www.qubes-os.org/doc/issue-tracking/) #…## Qubes OS release Latest as of posting, 4.1.0 ### Brief summary I manually unplugged every drive on my computer except for the target drive for the installation, which was all free space unpartitioned. Installer ran typically, chose automatic for the installation type. Booted into the OS' configuration and then the full OS. GRUB is verified to have worked because I managed to see it when initially booting for configuration and because of a later restart due to a display artificating and then system lockup problem I had that I attribute to Nvidia. After using another drive and then unplugging it, and plugging the Qubes drive back, there was no detectable boot source. I booted a live OS and found that the partition structure was intact but didn't investigate further and reinstalled Qubes. I then got the idea to see if this issue happened if I BIOS disabled drives instead of unplugging them. I disabled my Qubes drive and enabled another, and booted into it fine. I then disabled my other drive and reenabled the Qubes drive and the same issue happened again where my system does not see any boot entries. The system does see the drive, and switching on CSM and legacy boot I can boot from the drive but get an error screen saying to boot from proper media. This second time, I _kind of_ fixed it but I must do these steps every time I remove the drive or disable it in BIOS. I lose the option to boot without the Xen hypervisor and the boot hiccups. I essentially have to boot my install media, run Anaconda rescue and: 1. Mount the bootloader partition 2. Copy the contents of /mnt/EFI/qubes/ to /mnt/EFI/BOOT/ 3. Rename grubx64.efi to bootx64.efi 4. Rename grub.cfg to bootx64.cfg 5. efibootmgr -v -c -u -L Qubes2 -l /EFI/BOOT/bootx64.efi -d /dev/sda -p 1 ### Steps to reproduce I believe the best way to reproduce this issue is to do a fresh install of Qubes on hardware similar to mine: Asus Prime Z-390-A Motherboard Intel i7-9700K CPU 16GB DDR4 RAM 1TB HDD Most notably, this motherboard. I will be filing a compatibility report soon, but I believe this motherboard may have something to do with how it reads the GRUB bootloader as it's configured for Qubes. Further, these are the only non-stock BIOS settings: - Disabling the Intel LAN Controller (it causes a PCI reset error and ends the last step of the configuration, doesn't matter since I don't use it, and I believe the fact that it's unplugged is the reason this issue happens) - Enabling Virtualization - Enabling Vt-d - Disabling all other drives ### Expected behavior The GRUB bootloader is supposed to appear after the BIOS initializes regardless of whether the drive was previously unplugged from the system or not (safely of course). ### Actual behavior Please read above. After unplugging the drive or disabling it in BIOS, the entry for GRUB is missing.

Fom · April 7, 2024, 12:33pm

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

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.

apparatus · April 7, 2024, 12:37pm

You can try this:

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

Fom · April 7, 2024, 1:14pm

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.

rustybird · April 7, 2024, 1:23pm

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)

Fom · April 7, 2024, 1:43pm

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.

rustybird · April 7, 2024, 1:51pm

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

github.com

QubesOS/qubes-dist-upgrade/blob/v4.1.5/qubes-dist-upgrade.sh#L159


      
          fi
          
          if ! OPTS=$(getopt -o trslxyu:n:f:jkp --long help,update,release-upgrade,dist-upgrade,template-standalone-upgrade,finalize,convert-policy,all-pre-reboot,all-post-reboot,assumeyes,usbvm:,netvm:,updatevm:,skip-template-upgrade,skip-standalone-upgrade,only-update:,max-concurrency:,keep-running: -n "$0" -- "$@"); then
              echo "ERROR: Failed while parsing options."
              exit 1
          fi
          
          eval set -- "$OPTS"
          
          # Common DNF options
          dnf_opts_noclean='--best --allowerasing --enablerepo=qubes-dom0-current-testing'
          extra_keep_running=()
          convert_policy=
          
          while [[ $# -gt 0 ]]; do
              case "$1" in
                  -h | --help) usage ;;
                  --all-pre-reboot)
                      update=1
                      release_upgrade=1
                      dist_upgrade=1

Fom · April 7, 2024, 2:02pm

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!