December 19, 2019 3:44 PM, "awokd' via qubes-users"
<qubes-users@googlegroups.com> wrote:
> Claudia:
>
>> My original thought was to just give each one its own directory in
>> /boot/efi/EFI/, but the /boot/efi/EFI/qubes/ path seems to be hard coded
>> somewhere, probably either in the grub2-efi package (which installs a
>> precompiled efi binary to that directory) or in a grub2-install hook
>> somewhere. Not sure which of those methods Qubes uses. At least, I
>> couldn't figure out any way to persistently change the name of the EFI
>> directory. Of course you could make your own directories by copying the
>> files. e.g. /boot/efi/EFI/qubes{0,1}/, but when it updates (or you
>> reinstall one of them), they would both try to install to
>> /boot/efi/EFI/qubes/ again. And you'd have to manually change the path
>> each time with efibootmgr.
>
> This is partly what I need to do anyways on an older UEFI system. I
> wrote a script that copies the updated files over to BOOTX64, and run it
> after every update that touches EFI. Shouldn't be too hard to add
> efibootmgr to it, and an edit to the .cfg file pointing at the
> appropriate root=. Ignore the redundant .efi copies at the end; I'm
> still not entirely sure which one my half broken UEFI implementation uses.
>
> rm /boot/efi/EFI/BOOT/init*
> rm /boot/efi/EFI/BOOT/vmlinuz*
> cp /boot/efi/EFI/qubes/init* /boot/efi/EFI/BOOT/
> cp /boot/efi/EFI/qubes/vmlinuz* /boot/efi/EFI/BOOT/
> cp /boot/efi/EFI/qubes/xen.cfg /boot/efi/EFI/BOOT/BOOTX64.cfg
> ls /boot/efi/EFI/qubes/xen-*.efi
> cp /boot/efi/EFI/qubes/xen-*.efi /boot/efi/
> cp /boot/efi/EFI/qubes/xen-*.efi /boot/efi/EFI/BOOT/
> cp /boot/efi/EFI/qubes/xen-*.efi /boot/efi/EFI/BOOT/BOOTX64.efi
>
I see. I'm guessing your firmware only attempts to read from
/boot/efi/EFI/BOOT/BOOTX64.efi, even if the menu entry has a different path? I
think an approach like this could work for managing EFI directories manually.
Automated by a script of course, but still manual in the sense it's not handled
by the OS.
I was really hoping there was a config setting or variable somewhere that could
change the EFI directory, e.g. to /boot/efi/EFI/<whatever>/. On systems that
use grub-install, this is specified by --bootloader-id= argument. So in that
case you may be able replace /usr/bin/grub-install with a wrapper script that
forces your desired --bootloader-id argument. However Fedora doesn't use
grub-install, it uses a package which installs a prebaked grubx64.efi binary
which is installed to the hardcoded path /boot/efi/EFI/fedora. This is in order
to support Secure Boot. I'm assuming Qubes does it the same way. I'm also
assuming that "fedora" gets changed to "qubes" by a patch or a compile-time
variable but is not configurable at runtime. Maybe there's an option in Yum/dnf
similar to apt's redirect option, to configure a file to be installed at a
different path than what it's packaged as. I have no idea.
I did some research, and apparently this is a very common flaw. In fact, Mint
uses the hardcoded directory /boot/efi/EFI/ubuntu/, meaning you can't dual boot
Mint and Ubuntu from the same ESP. But the good news is that you can use more
than one ESP, as long as your firmware supports it (it sounds like most of them
do). So that's also an option. I was originally worried it would cause problems
that they're using the same UUID, but actually they don't. I was confusing the
filesystem UUID, which is unique, with the GPT partition identifier (GUID),
which is a magic value. And I remembered you could also mount them by label
anyway.
https://www.zdnet.com/article/hands-on-linux-uefi-multi-boot-part-three-problem-solving/
So I guess I could use /boot/efi/EFI/qubes/ as a sort of staging area for both
instances of Qubes, and then religiously after every update, run a script to
move the directory to /boot/efi/EFI/qubes{0,1,...}, and then delete the
newly-created efibootmgr entry for \EFI\qubes\grubx64.efi and (if necessary)
re-create the one for \EFI\qubesN\grubx64.efi. Or, perhaps there's some way to
prevent modification of efibootmgr entries so the package install hook (or
whatever) can't mess with it.
I decided I'm going to try the dual-ESP approach first and see if it works. If
not, then I'll try the EFI directory hack.
I formatted my disk like: ESP, /boot, root, ESP, /boot, root, (swap); and
installed Qubes into the first "slot". I still have to install another Qubes
instance into the second "slot" and make sure they both work. I'll follow up
when I do.
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/f5c224eda7a05920ab205a2224c58b64%40disroot.org.
