feat(dracut): remove old dracut.conf

[aafeijoo-suse]

The configuration parameters in /etc/dracut.conf are being overridden by /etc/dracut.conf.d and /usr/lib/dracut/dracut.conf.d, which should be the opposite, the place for the user to override distribution/package configuration.

Since the user can set his own configuration in /etc/dracut.conf.d/*.conf, and this file only creates confusion (and bug reports in downstream distributions), we can get rid of it.

The other option would be to source it after all the dracut.conf.d snippets, but we should do something with it. This topic was already discussed a long time ago on the kernel mailing list:

• https://marc.info/?l=initramfs&m=129863757626118&w=2
• https://marc.info/?l=initramfs&m=126882349907058&w=2

Checklist

• [X] I have tested it locally
• [X] I have reviewed and updated any documentation if relevant
• [ ] I am providing new code and test(s) for it

[aafeijoo-suse]

Thanks for doing this. I think it'd make sense to split this into two changes, with the first just carrying the Makefile and dracut.conf hunks. A deprecation message should perhaps initially be added for the --conf parameter instead of immediately proceeding with complete removal.

Yes, you're right, this kind of things should be done with a deprecation warning in advance... but I don't want to see this warning for years, so I'd enter a short time frame, like "this option will be removed in the upcoming 059 release". That said, if everyone agrees to remove it completely.

[johannbg]

Hmm is not the (un)official standard these days on the core/baseos level that main/default configuration files always exist if used either as straight up configuration files or in the case of the configuration being set during compilation as a commented out file, under the project name under the vendor namespace as /usr/lib/{project}/project-main.conf which then gets created ( via sd-tmpfiles ) under the administrator namespace for the project as in /etc/{project}/project-main.conf for the local administrators to override and change.

In other words we should not remove the dracut.conf file based on that.

I think we should not support more than two most recently release of dracut here upstream at any given point in time hence deprecation warnings should not exist longer than any two releases ( the release it gets introduced in and the next one ). Now what that means in practice ( assuming we ever manage to evolve to the point we start making monthly releases ) if we deprecate stuff ( with a warning ), it gets deprecated every third month and the deprecation message exist for two months from the time it gets introduced.

[johannbg]

@LaszloGombos your take on this.

[LaszloGombos]

I agree with @ddiss in that "just carrying the Makefile and dracut.conf hunks" first would make sense to me.

I also think that --conf option is useful if changing /etc is not an option (read-only /etc mount, etc). I would rather keep --conf. If there is a strong reason for removal, perhaps we can also support having .conf file under /run .

[stale[bot]]

This issue is being marked as stale because it has not had any recent activity. It will be closed if no further activity occurs. If this is still an issue in the latest release of Dracut and you would like to keep it open please comment on this issue within the next 7 days. Thank you for your contributions.

[johannbg]

@aafeijoo-suse, @LaszloGombos @ddiss so where are we all with this one in the dialog so we can either move it forward and or close it

[aafeijoo-suse]

Hmm is not the (un)official standard these days on the core/baseos level that main/default configuration files always exist if used either as straight up configuration files or in the case of the configuration being set during compilation as a commented out file, under the project name under the vendor namespace as /usr/lib/{project}/project-main.conf which then gets created ( via sd-tmpfiles ) under the administrator namespace for the project as in /etc/{project}/project-main.conf for the local administrators to override and change.

In other words we should not remove the dracut.conf file based on that.

Al least the distros I know closely (openSUSE, Fedora and Debian) create their vendor configuration files under /usr/lib/dracut.conf.d/*.conf or /etc/dracut.conf.d/*.conf and leave /etc/dracut.conf empty, but if any distro follows the standard you mention... then maybe we should not remove the dracut.conf file and leave things as they are now...

[johannbg]

We always end up having to ship some sort of default configuration file regardless what downstream decides to do ( use it or not use it ) but at the same time we need to clean this up with something along the lines of changing

from /etc/dracut.conf $dracutsysrootdir/etc/dracut.conf to /etc/dracut/dracut.conf $dracutsysrootdir/etc/dracut/dracut.conf

from /etc/dracut.conf.d/ $dracutsysrootdir/etc/dracut.conf.d to /etc/dracut/conf.d/ $dracutsysrootdir/etc/dracut/conf.d

from /usr/lib/dracut/dracut.conf.d/ $dracutbasedir/dracut.conf.d to /usr/lib/dracut/conf.d/ $dracutbasedir/conf.d

Each module we provide should also come with an module conf for it that enables it so something like nr-module-name.conf which contains "add_dracutmodules+=" module " which results in 00-foo.conf for the module foo and contains "add_dracutmodules+=" foo " which enables the module.

If agreed upon you can update your PR according to the above path changes and we can put the pr in the 059 milestone. The conf file for the modules we handle in separated pr

@LaszloGombos whats your take on the above

[stale[bot]]

This issue is being marked as stale because it has not had any recent activity. It will be closed if no further activity occurs. If this is still an issue in the latest release of Dracut and you would like to keep it open please comment on this issue within the next 7 days. Thank you for your contributions.