I wanted to install the 4.1 release to try, but the installer for some reason decided to overwrite the entry in uefi. Why didn’t the developers take care that the installer writes the boot loader to the drive to the fat32 partition in rather than to the uefi? Obviously, users would like to store the bootloader on the drive, and not in uefi.
How do I get the boot back on the first system?
You can use efibootmgr to see your boot entries and create new ones, so you should be able to choose which one to boot – you may want to open an issue so the installer would not just overwrite the boot entry without asking.
Use efibootmgr -v to show the new boot entry. You’ll have to determine the proper UUID to use (I’ll let you dig for that, should have to dig myself 
) for your your first Qubes install, and then forge a new entry for efibootmgr -c.
I’m sorry, it’s hard for me to translate from English. Does this topic contain a command that will write an entry to uefi for my first system? Cannot boot into Qubes 4.1 - what has changed in 4.1 boot routine (UEFI)?
efibootmgr -v -c -u -L QubesOS -l /EFI/qubes/grubx64.efi -d /dev/sda -p 1
Come to think of it… When you make 2 installs like that, that will not create a second EFI boot partition, so the things may be a bit mixed up in there – probably the xen.efi that is used by the 4.0.4 boot got overwritten by the 4.1 one, it’s not clear to me if it’s easy to fix things (and esp. to let them not be broken again by a dom0 update on one side once you fix it). But you still may be able to get one boot entry for each, in much the same way I added a xen.efi line just in case for testing on my 4.1.
What you likely need is to:
- get a
xen.efibinary from 4.0.4, and get it into/boot/efi/EFI/qubes/, maybe under a different name to avoid clashing with the one from 4.1, but they will both want to use the samexen.cfganyway - get a
xen.cfgfrom 4.0.4 to get the proper parameters, which you’ll need to tune anyway for your 4.0.4 luks volume - get the EFI boot entry used by you 4.1 install with
efibootmgr -v(should be bootinggrubx64.efi), and forge another one forefibootmgr -c, specifying yourxen.eficopy instead
The big takeaway of the adventure, besides learning how Qubes boots in more details, will be "don’t try to do unsupported things with your main install, that can get tricky "
Isn’t it easier to put the bootloader on the drive of the first system? What’s the right way to do it? I put bootx64.efi in the fat32 partition but the system does not boot to the end and is spouting a bunch of errors.
With UEFI systems the bootloader is precisely what is in your efi partition.
With 2 drives if you did not keep the first one connected, my first answer would be way to go.
That looks possible. Maybe use “QubesOS 4.0” as label to avoid flashing with your 4.1 entry.
this command worked from rescue mode. first system is restored
But the question of placing the bootloader on the drive remains open. I want to remove the entry from the uefi and then use only the boot loader from the drive