mkosi
mkosi copied to clipboard
Separate boot partition when using BIOS booting
(Originally brought up in https://github.com/systemd/mkosi/pull/489#issuecomment-795469878)
Currently mkosi
does not support BIOS boot when gpt_squashfs
is used. Furthermore, when BIOS booting is used with --verity
enabled, dm-verity
is not used at all: no roothash
is passed on the kernel command line, and hence systemd
won't set up the device: the root partition is used as-is. Indeed, since grub.cfg
is created on the very block device for which integrity will be validated, this is impossible.
I believe this could be worked around if, similar to the ESP for UEFI boot, a separate /boot
partition would be used in the GPT image. Using this approach, a roothash
could be injected in grub.cfg
after the dm-verity
data has been calculated. It would also allow for a SquashFS root partition to be used (I believe).
Of course, this implies the kernel and initrd (and whatever else sits in /boot
) doesn't fall under dm-verity
validation, but the Grub wouldn't check/use these checksums anyway.
(What would be really neat is if we could simply use root=gpt-auto
, even with BIOS boot, but from what I understood systemd
doesn't support this in non-UEFI environments.)
Of course, this implies the kernel and initrd (and whatever else sits in /boot) doesn't fall under dm-verity validation, but the Grub wouldn't check/use these checksums anyway.
This is the same when using an ESP right? If so, it's not a problem.
This generally looks OK to me but needs some specifics cleared out like which partition do we put grub on? Can we reuse the XBOOTLDR partition for this?
Of course, this implies the kernel and initrd (and whatever else sits in /boot) doesn't fall under dm-verity validation, but the Grub wouldn't check/use these checksums anyway.
This is the same when using an ESP right? If so, it's not a problem.
Indeed.
This generally looks OK to me but needs some specifics cleared out like which partition do we put grub on? Can we reuse the XBOOTLDR partition for this?
Putting this on XBOOTLDR
would make sense as far as I'm concerned (would put the grub2
directory under /boot/grub2
as seen from the host, which is quite 'standard'). However, XBOOTLDR
is, as far as I'm aware, currently an optional partition, which should then change.
I don't particularly mind making XBOOTLDR required when using grub. Any idea how backwards compatible this would be? If the grub files are still accessible at the same paths, I think we can do this by default instead of putting it behind an option.
Going through the Boot Loader Specification and what systemd-gpt-auto-generator does with the XBOOTLDR
partition, it appears to me using said partition for this purpose is fine and as designed.
However, what systemd-gpt-auto-generator
does may not matter much anyway because this is for BIOS based systems which it doesn't support :wink:
Yeah, let's use XBOOTLDR for this. Only thing I'm unsure about is whether we should do this unconditionally or not. I'm not familiar enough with grub to know whether we'd break any important use cases by doing this or not. I think we can get away with automatically enabling XBOOTLDR for BIOS setups and installing grub there. If users complain (or if we figure out it breaks some important use case), we can see about making it configurable.
I haven't had time to work on this, however still very interested in the feature.
One more thought: instead of injecting the roothash
in grub.cfg
, we could write it in some file (next to grub.cfg
) which is source'd by Grub (instruction in grub.cfg
) and used as a variable where applicable. Rationale for this: we're building a systen where we want to use mkosi
-built images both as the boot disk (e.g., flashed on a USB-stick), as well as using a loop-device from a Grub installed on the host machine (fetching the kernel and initrd images out of the disk image using Grub's loopdev functionality). If at that point we can also source
this file containing the roothash (and ignore the grub.cfg
from the disk image altogether), this would make things a lot easier.
We don't support BIOS anymore, so closing this issue