Assuming you are booting Qubes R4.0 with UEFI, xen.efi is the only thing your BIOS would load that would allow the system to boot Qubes. Unless your BIOS searches for the next EFI binary in the directory, your selection of xen.cfg should not have worked.
- xen.efi: An EFI binary that contains Xen. This is the “bootloader” that your BIOS will load to start up Qubes.
- xen.cfg: xen.efi references this file to determine boot options and which dom0 kernel to load
- vmlinuz/initramfs: dom0 kernel and initramfs
If you kill any of these, your system will not boot.
What you do want to do is watch the free space in /boot and /boot/efi. Some EFI partitions can be tiny in size - if you are doing a fresh install without dual booting, it’s a good time to make it large enough.
When you perform a Qubes update, a new kernel (vmlinuz) gets installed and a new initramfs gets generated. The system keeps the latest 3 kernels. I’ve seen multiple times where the initramfs generation fails due to lack of space, and upon reboot, the system doesn’t boot. (For an UEFI R4.0 boot), that requires using a rescue disk and updating which kernel should boot in xen.cfg. If you boot with legacy BIOS it’s much easier since you only have to select a different GRUB menu option. Qubes R4.1 with UEFI does use GRUB; R4.0 with UEFI is the headache when your system doesn’t boot.
Boot order on R4.0 with UEFI:
[BIOS/UEFI]
--> [xen.efi] --> loads Xen hypervisor
--> [Xen reads xen.cfg] --> loads dom0 linux kernel (vmlinuz)
--> [dom0 linux kernel loads initramfs] --> transfers control to initramfs init
--> [initramfs init] --> gets root partition ready (eg unlock LUKS-encrypted disk) --> transfers control to rootfs /init (systemd)
--> [rootfs init/systemd] --> starts system