module idea: Fedora Atomic `initramfs-setup` module
Closed this issue · 16 comments
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:
- It relies on some unnecessary checks, like version file checks, which I would want to avoid
- It doesn't support automatic removal of untracked initramfs files (it has to be done manually by the user)
- It doesn't support detailed log messages, which would indicate if only initramfs changes are applied, initramfs rebuild only, or both.
- It doesn't support automatic rebuild of initramfs when dracut module is included by the live-user (it requires adding rebuild file manually)
- It doesn't support abstracted modifications, like in .yml files, which makes it easier for maintainers to add their own modifications
- It doesn't support adding dracut-related modifications for maintainers (which would detect that & automatically rebuild initramfs, unlike
hardware-setup)
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:
- Supports all files, not just files from
/etc - Very rare, but some programs like
system76-powermake modprobe files & rebuild initramfs automatically. If Fedora version of system76-power gains rpm-ostree support, it would collide withinitramfs-setupimplementation, where they would fight with tracking & untracking files, leading to potential bootloop scenario.
I made the issue here for rpm-ostree support of it:
szydell/system76-power#55
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.
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
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:
- user has to make
rebuildfile after including dracut config rebuildfile would be deleted immediately after initramfs rebuilding finished
I would remove the rebuild file before starting the rebuild, incase it fails
I would remove the
rebuildfile before starting the rebuild, incase it fails
Added support for this.
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.
Also updated main post with concern for RPMs which use modprobe files for the program's functionality.
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.
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.
Having mulled over this for a while i think the image should be using
rpm-ostree initramfsarguments while users should focus ondracut.conffiles 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 forrpm-ostree initramfswhere some arguments can only be provided once, but can be provided multiple times indracut.conffiles.
hardware-setupshould 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 bedracut.conffiles 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.
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
even with
dracut.conffiles you will have to rebuild initramfs but the good thing with the image hijacking therpm-ostree initramfsargs would be that the user cannot mess them up ;)
dracut.conffiles are in/etcso that shouldnt be a problem withinitramfs-etcwhich 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.
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:
#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.
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.
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..
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)
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)
@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