search

blue-build / modules

BlueBuild standard modules used for building your Atomic Images
Apache License 2.0
23 stars 25 forks source link

module idea: Fedora Atomic `initramfs-setup` module #101

Closed fiftydinar closed 3 months ago

fiftydinar commented 6 months ago

Introduction

It is occasionally discussed in Discord how universal & standardized initramfs-setup would be beneficial. Here's my point of view of that.

What are the benefits of initramfs-setup?

Benefit is that you can cleanly deploy your changes to users, which you can not do with rpm-ostree kargs.

rpm-ostree kargs type of service relies on arguments for modifications, while initramfs-setup relies on files. If you try to make rpm-ostree kargs implementation clear, you would have to assume which exact kernel argument user has, including the value after =, while with initramfs you just delete the file & service automatically untracks that file.

This would make rebase between images more seamless, without worrying if user has that harmful karg remained with your image.

To who would benefits apply?

Benefits would apply to images which need this kind of setup, like surface, bazzite, bluefin & other images. To all images too, even if they don't employ those modifications, as it would ensure cleaner rebase.

It would be also beneficial for all developers/contributors in Universal Blue & with the following, for all end-users.

Contributions would be easier if this is standardized, either here, or in separate repo.

What is the best implementation of initramfs-setup?

Currently, the best implementation of this opinionated initramfs-setup is in Bazzite, mostly done by @HikariKnight. It's called bazzite-hardware-setup. I will try to ignore image-specific things, so I will focus on initramfs parts only.

It is a good implementation, but it can be done better:

How to make initramfs-setup better?

I want to introduce you to my unofficial initramfs-setup startingpoint module.

It solves almost all of those issues & makes initramfs-setup more reliable.

Only things that are not solved:

1: I can make the implementation of rpm-ostree initramfs too. However, the reason why rpm-ostree initramfs-etc is preferred is because it doesn't constantly rebuild the initramfs when the update is installing. 2: This can be solved by including file called tracked-whitelist, where we would whitelist those conflicted config files manually. System76-power uses these files: /etc/modprobe.d/system76-power.conf & /etc/modules-load.d/system76-power.conf. Automatic solution which detects which files are from RPM & which are from initramfs-setup is impossible imo.

Details about unofficial initramfs-setup module

https://github.com/fiftydinar/gidro-os/tree/main/modules/initramfs-setup

You want to help?

Let's discuss.

Testing & reporting the function/issues of my unofficial module would also be very welcome.

HikariKnight commented 6 months ago

i like the idea of it being more automatic, the current implementation being manual is because of how the rest of bazzite-hardware-setup worked to begin with. bumping its version when bazzite has new changes it needs to apply (often related to hw support). the rebuild file just being a way to force trigger the initramfs part without having to rerun all the hwsupport stuff again

fiftydinar commented 5 months ago

Automatic dracut detection + initramfs rebuild is much harder that I thought.

I removed support for it as it didn't work properly.

I will probably have to rely on logic similar to Bazzite's:

HikariKnight commented 5 months ago

I would remove the rebuild file before starting the rebuild, incase it fails

fiftydinar commented 5 months ago

I would remove the rebuild file before starting the rebuild, incase it fails

Added support for this.

fiftydinar commented 5 months ago

I separated the OS initramfs config to be in this file:

/usr/share/ublue-os/initramfs/tracked

Instead of this:

/usr/etc/ublue-os/initramfs/tracked

User modification still remains here:

/etc/ublue-os/initramfs/tracked-custom

Which can be reset back to defaults by copying the same file from: /usr/etc/ublue-os/initramfs/tracked-custom

This will prevent user from modifying the file which is strictly maintainer-only.

fiftydinar commented 5 months ago

Also updated main post with concern for RPMs which use modprobe files for the program's functionality.

fiftydinar commented 5 months ago

rpm-ostree initramfs is now disabled when using this module.

I also added support for adding dracut .conf files.

However, it's not tested if just including those works, as I did not set it to rebuild initramfs when those are added.

/usr/lib/dracut/dracut.conf.d location is used for those files.

I can change it to /usr/etc/dracut.conf.d if dracut config files are not applied

EDIT: I changed the location to /usr/etc/dracut.conf.d now.

HikariKnight commented 5 months ago

Having mulled over this for a while i think the image should be using rpm-ostree initramfs arguments while users should focus on dracut.conf files and hardware-setup should facilitate that. It would reduce the scope and complexity as it seems there are some strict limitations to some of the arguments for rpm-ostree initramfs where some arguments can only be provided once, but can be provided multiple times in dracut.conf files.

hardware-setup should then just host the logic to assemble the arguments and set up initramfs on boot (when needed) depending on hardware for the specific image. All user configs should then be dracut.conf files as all the initramfs arguments have an equivalent in the config files.

fiftydinar commented 5 months ago

Having mulled over this for a while i think the image should be using rpm-ostree initramfs arguments while users should focus on dracut.conf files and hardware-setup should facilitate that. It would reduce the scope and complexity as it seems there are some strict limitations to some of the arguments for rpm-ostree initramfs where some arguments can only be provided once, but can be provided multiple times in dracut.conf files.

hardware-setup should then just host the logic to assemble the arguments and set up initramfs on boot (when needed) depending on hardware for the specific image. All user configs should then be dracut.conf files as all the initramfs arguments have an equivalent in the config files.

Since you are more experienced with rpm-ostree initramfs, I think this is indeed better than classic initramfs.

I would maybe use dracut.conf for both OS & user modifications if it's more reliable. OS dracut configuration would be in 1 file named something like bluebuild-initramfs-setup.conf.

We would need to document that not all dracut options are supported though, like cmdline (kernel arguments). Dracut configuration is indeed more advanced for certain things, but it's very hard to document it for ordinary users, who just want to fix/modify their hardware.

However, I think that initramfs-etc would be still more reliable, even if limited with /etc files only. It's also easier to use due to easier format, unless a wrapper is made for dracut config files with different format (good amount of work would be needed).

Main drawback of rpm-ostree initramfs is it takes a lot of time to rebuild initramfs. Some users even thought that their system went into bootloop due to this.

HikariKnight commented 5 months ago

even with dracut.conf files you will have to rebuild initramfs but the good thing with the image hijacking the rpm-ostree initramfs args would be that the user cannot mess them up ;)

dracut.conf files are in /etc so that shouldnt be a problem with initramfs-etc which i have not fiddled with

fiftydinar commented 5 months ago

even with dracut.conf files you will have to rebuild initramfs but the good thing with the image hijacking the rpm-ostree initramfs args would be that the user cannot mess them up ;)

dracut.conf files are in /etc so that shouldnt be a problem with initramfs-etc which i have not fiddled with

Yeah, but rpm-ostree initramfs rebuild takes significantly more time compared to rpm-ostree initramfs-etc, as it rebuilds full initramfs everytime something changes & on every system update, while rpm-ostree initramfs-etc only rebuilds initramfs partially (/etc) part which is much faster & only when you add new file. System update automatically tracks changes from edited existing files without the mentioned issues.

fiftydinar commented 3 months ago

Thinking about this, this module wouldn't suffice as an official module, since it targets Fedora Atomic only.

However, I would still offer it unofficially, until some better solution comes.

I would also rewrite this module some day to conform to the new bash coding & documentation guidelines, which is in-progress here: https://github.com/blue-build/modules/pull/175

This would include the switch to standardized config into 1 YAML file, instead of scattered text files & then processing them through awk, sed, grep or whatever.

Main logic of applying & removing initramfs-etc arguments, along with rebuilding initramfs would stay the same.

Handling of dracut config still needs to be tested, as copying them to /etc may not be enough.

fiftydinar commented 3 months ago

I'm closing this issue, since initramfs-etc doesn't fit into the official BlueBuild bash module scope.

I will still occasionally update here, if some changes happen related to this module only.

For more recent updates about handling of initramfs & kernel arguments, see Universal Blue discussion either on GitHub or Discord, since Bazzite plans to get rid of their current rpm-ostree initramfs implementation.

xynydev commented 3 months ago

I'm closing this issue, since initramfs-etc doesn't fit into the official BlueBuild bash module scope.

Why not? I'm not opposed to actually useful modules that only work on Fedora Atomic, but I will confess that I was never quite certain on what this module is / would be used for, so maybe that's one reason to not include the module, heh..

m2Giles commented 3 months ago

All, see this as a way to have initramfs as part of the build step. Purpose for generating initramfs - Plymouth changes, enabling additional dracut_modules that are not present in default, and doing early loading of kernel modules (mainly nvidia to avoid text fallback mode in plymouth)

https://github.com/ublue-os/bluefin/commit/35f9340871fd66408976ef13f207005fa4e83527

fiftydinar commented 3 months ago

All, see this as a way to have initramfs as part of the build step. Purpose for generating initramfs - Plymouth changes, enabling additional dracut_modules that are not present in default, and doing early loading of kernel modules (mainly nvidia to avoid text fallback mode in plymouth)

ublue-os/bluefin@35f9340

@qoijjj This is the way forward instead of my solution

If some kargs that secureblue uses can be set through initramfs, then this is how it should be done.

Encryption dracut drivers in the commit that Bluefin added is useful for secureblue imo