installer should replace /boot/efi/qubes/xen.efi if it exists

[freddierice]

Qubes OS version (e.g., R3.2):

R4.0-rc1

Affected TemplateVMs (e.g., fedora-23, if applicable):

n/a

---

Expected behavior:

/boot/efi/qubes/xen.efi should be updated to the newest efi file.

Actual behavior:

If the file /boot/efi/qubes/xen.efi already exists (i.e. from a previous install of qubes), it will not get replaced with a newer version.

Steps to reproduce the behavior:

1. Install Qubes 3.2 with automatic partitioning.
2. Remove the LUKS partition.
3. Install Qubes 4.0-rc1 with automatic partitioning

General notes:

I found the source of the error in anaconda/pyanaconda/bootloader.py on line 1855:

        if not os.path.exists(
                "{}/{}".format(iutil.getSysroot() + self.config_dir, "xen.efi")):
            xen_efi = [x for x in os.listdir(iutil.getSysroot() + self.config_dir) if
                       x.startswith('xen-') and x.endswith('.efi')][0]
            shutil.copy("{}/{}".format(iutil.getSysroot() + self.config_dir, xen_efi),
                        "{}/{}".format(iutil.getSysroot() + self.config_dir, "xen.efi"))
        rc = self.efibootmgr("-c", "-w", "-L", productName,
                             "-d", boot_disk.path, "-p", boot_part_num,
                             "-l",
                             self.efi_dir_as_efifs_dir + "\\xen.efi",
                             root=iutil.getSysroot())

The newest xen.efi does not get copied if an older one exists.

Related issues:

In the specific case of upgrading from Qubes 3.2 to 4.0, there is a switch from Xen 4.6 to 4.8, which in turn caused countless errors in the interaction between the Xen tooling and the Xen HVM.

[freddierice]

I'd like to contribute, but there are a couple of ways that this issue could be fixed.

1. Allow for both qubes 3.2 and qubes 4.0 compatible xen.efi to exist (i.e. name the 4.0-rc1 compatible xen.efi something like /boot/efi/qubes/4.0-rc1.efi)
2. Overwrite the previous xen.efi, breaking qubes 3.2.

Realistically, a user should only have one version of qubes on their computer. If 2) is the expected behavior, then the user should be notified in the installer.

Thoughts?

[freddierice]

I'd like to contribute, but there are a couple of ways that this issue could be fixed.

1. Allow for both qubes 3.2 and qubes 4.0 compatible xen.efi to exist (i.e. name the 4.0-rc1 compatible xen.efi something like /boot/efi/qubes/4.0-rc1.efi)
2. Overwrite the previous xen.efi, breaking qubes 3.2.

Realistically, a user should only have one version of qubes on their computer. If 2) is the expected behavior, then the user should be notified in the installer.

Thoughts?

[marmarek]

I think it should be 2). One subdirectory in /boot/efi/EFI should be used only by one OS. It isn't only about xen.efi, but also xen.cfg, kernel, initrd.

BTW there is a way to have multiple Qubes instances at the same machine - using different subdirectories in /boot/efi/EFI. There is no UI for that, but you can manually copy/rename "qubes" to for example "qubes3.2", "qubes4" etc, then use efibootmgr to adjust boot entries. I don't think we need to support this automatically.

[marmarek]

I think it should be 2). One subdirectory in /boot/efi/EFI should be used only by one OS. It isn't only about xen.efi, but also xen.cfg, kernel, initrd.

BTW there is a way to have multiple Qubes instances at the same machine - using different subdirectories in /boot/efi/EFI. There is no UI for that, but you can manually copy/rename "qubes" to for example "qubes3.2", "qubes4" etc, then use efibootmgr to adjust boot entries. I don't think we need to support this automatically.

[marmarek]

Actually I'm surprised this happens, because installation of xen-hypevisor package should replace xen.efi. See here:
https://github.com/QubesOS/qubes-vmm-xen/blob/d48f41f123f33387fa5691231466be3e38ea7c16/xen.spec#L533-L549

Anyway, I'm going to merge the current fix, until the code above start working again.

[marmarek]

Actually I'm surprised this happens, because installation of xen-hypevisor package should replace xen.efi. See here:
https://github.com/QubesOS/qubes-vmm-xen/blob/d48f41f123f33387fa5691231466be3e38ea7c16/xen.spec#L533-L549

Anyway, I'm going to merge the current fix, until the code above start working again.