search

ublue-os / main

OCI base images of Fedora with batteries included
https://universal-blue.org/images/main/
Apache License 2.0
464 stars 28 forks source link

Add Initramfs LUKS related dracut configuration to all images #593

Closed m2Giles closed 1 day ago

m2Giles commented 2 days ago

Describe the package

Currently a user will have to create a local initramfs if they wish to use tpm2, fido, and pkcs11 for LUKs deceyption.

Information on the package

We've been building a custom initramfs in bluefin and Bazzite for a few months. With Nvidia now requiring early loading for Wayland support in Gnome, we are now building a custom initramfs in all but our main images.

Since we are already building them, we can enable hardware support.

Image

All Images

bsherman commented 2 days ago

I've chatted with @KyleGospo a bit about this topic.

First, I 100% think we should be adding support for tpm2/fide/pkcs11 LUKS ulock to our dracut configs... and given we already have an RPM related to this ( see https://github.com/ublue-os/config/tree/main/build/ublue-os-luks ), I think we can accomplish that goal by adding this file from bazzite to the config repo for the ublue-os-luks RPM build. I'd probably rename it to 90-ublue-luks.conf.

Second, I'm having doubts about actually building the initramfs as part of the main image. By adding the config file, we'll be enabling this for any user who runs main and chooses to build it at runtime, plus enabling all downstreams (including hwe, bazzite, bluefin/aurora) to automatically get this benefit, BUT... by building initramfs in main we'll add a few hundred MB to that image which also gets wasted in all the downstreams.

Perhaps we add documentation for anyone who REALLY wants to run main images on how to rebuild this... as well as adding some support for this to our image template.

p5 commented 1 day ago

Adding the required configs but leaving the generation sounds good to me.

We probably already do it ourselves everywhere, but we should document that it's good to call the generation as one of the final commands in any downstream build.

bsherman commented 1 day ago

We probably already do it ourselves everywhere, but we should document that it's good to call the generation as one of the final commands in any downstream build.

Yes, where to do that documentation is one of my outstanding unknowns.