GRUB (re)installation: Qubes OS/Xen specifics (?)

User Support General
1

Hello.

TL;DR
I would like to learn if GRUB bootloader installation/core image creation commands Qubes OS and/or Xen specific, comparing to usual Linux distributions.

Reasoning
To use detached LUKS header without detached /boot partition, I must generate GRUB core image manually to embed early config file. Otherwise GRUB can not know about existence of encrypted device.

Below is example of how I would accomplish this task on ArchLinux, adapted for Qubes OS paths.
Here I omit all LUKS initramfs and user space configuration, since my question is about early boot.
For AES cipher, SHA-512 hash, pbkdf2 key, Btrfs root, GPT/FAT32 EFI partition:

grub-pre.cfg

cryptomount -H (hd1,gpt1)/header.img (hd0)
set root='(crypto0)'
set prefix='($root)/root/boot/grub2'
insmod normal
normal

# grub-mkimage -p '(crypto0)/boot/grub2' -O x86_64-efi -c /boot/grub2/grub-pre.cfg -o /boot/efi/EFI/qubes/grubx64.efi gcry_sha256 gcry_sha512 normal luks2 part_gpt cryptodisk gcry_rijndael pbkdf2 fat btrfs

Such simple config not seem to work on Qubes OS: GRUB does nothing.
The reason probably is my zero knowledge about Qubes OS boot process specifics and Xen.

Problem
I tested that detached LUKS header works with detached /boot partition, where GRUB have no need to care about header in early boot. However, I prefer to have /boot under root: less points of failure.

All guides on the forum I was able to find are for detached /boot partition.

Question
Which commands with which command line arguments Qubes OS executes on first install and updates to (re)install GRUB? Perhaps there is some wrapper in place?

Thank you for reading!
Would be very grateful for any hints & happy to learn.

2

Hello @dT5qZWg4AJ9m,

Maybe you can regenerate a grub image by adding the modules listed in the following link:

1 Like
3

It’s extremely helpful for my configuration to have such list of modules nearby.
And it’s exactly what I was looking for. Thank you!

While trying to implement it, I actually found out why GRUB just sit and do nothing.
Prepare to laugh, since it a little bit dumb. GRUB 2.06 seem to have no idea about -H option existence.
Most likely devs just added it into latest 2.12 release only.

Looks like I have to wait until Fedora (and Qubes OS?) updates GRUB package, whenever it happens.

Unless there are other options, like compiling GRUB myself or getting latest version by some other means. But I don’t know where to start about it.

1 Like
4

To compile it yourself, the best way is to use qubes-builderv2 and modify
qubes-grub2 repository to build a package for dom0, but it would be a lot of work as you would need to explore the changes between 2.06 and 2.12, and adjust the patches in that repository.

So it might be better to try creating a custom patch for 2.06 by referencing the relevant commits from upstream grub with git log --grep=crypto, etc.

5

Update to grub 2.12 will happen at some point, but I wouldn’t hold my breath… Fedora uses effectively a fork of grub2 - with over 300 patches on top, and some of those patches are relevant to the setup we use in Qubes. We have some subset of those (GitHub - QubesOS/qubes-grub2: grub2 packaging), but still updating is a massive work. Ideally, Fedora should upstream all (or at least most) of their patches, and then updating would be simpler, but it’s unlikely to happen anytime soon. If they update to grub 2.12, then updating qubes package will be easy(ish). Otherwise, it will wait until somebody has enough time to rebase all the patches we actually need.

Until then, backporting relevant functionality might be easier (but might also be not trivial).