I just noticed the following change when I updated my Fedora Linux 42 PC. diff --git a/dkms/framework.conf b/dkms/framework.conf index 20ecc86..7d180f3 100644 --- a/dkms/framework.conf +++ b/dkms/framework.conf @@ -34,8 +34,8 @@ # Location of the key and certificate files used for Secure boot. $kernelver # can be used in path to represent the target kernel version. # -# NOTE: If any of the files specified by `mok_signing_key` and -# `mok_certificate` are non-existent, dkms will re-create both files. +# NOTE: If any of the files specified by `mok_signing_key` and `mok_certificate` +# are non-existent, dkms will re-create both files. # # mok_signing_key can also be a "pkcs11:..." string for PKCS#11 engine, as # long as the sign_file program supports it. @@ -50,8 +50,15 @@ modprobe_on_install="true" # parallel_jobs=2 # Compression settings DKMS uses when compressing modules. The defaults are -# used, for reasonable compression times. One might instead wish to use -# maximum compression, at the expense of speed when compressing. +# used, for reasonable compression times. One might instead wish to use maximum +# compression, at the expense of speed when compressing. # compress_gzip_opts="-6" # compress_xz_opts="--check=crc32 --lzma2=dict=1MiB -6" # compress_zstd_opts="-q --rm -T0 -3" + +# Command to run at the end of every DKMS transaction, for example after a new +# kernel has been installed on the system and all modules have been succesfully +# built and installed. +# The command listed is executed if set to any non null value. $kernelver can be +# used in path to represent the target kernel version. +post_transaction="dracut --regenerate-all --force" That last line is *really* bad because if an update generates a non-functioning initramfs, *all* the initramfses will be corrupted, not just the latest one, and the system would be rendered unbootable. This completely defeats the purpose of having "fallback" boot kernels. Reproducible: Always Steps to Reproduce: 1. sudo dnf update Actual Results: post_transaction="dracut --regenerate-all --force" is added to /etc/dkms/framework.conf Expected Results: post_transaction="dracut --regenerate-all --force" should not be added to /etc/dkms/framework.conf
(In reply to Gregory Lee Bartholomew from comment #0) > That last line is *really* bad because if an update generates a > non-functioning initramfs, *all* the initramfses will be corrupted, not just > the latest one, and the system would be rendered unbootable. This completely > defeats the purpose of having "fallback" boot kernels. I don't think this is an easy logic to deal with. There are multiple cases to cover: - Package that updates a module and there is only one kernel installed. The initrd is rebuilt, otherwise you have the old module in. And if it's rebuilt, you don't have a fallback to boot into. And if it's not rebuilt, then your system is probably loading the old module even if the new one is listed. - Package that updates a module and there is more than one kernel installed. Without targeting all kernels, you would get only one initrd updated and then DKMS reporting an updated module for the other kernel but still bundling the old modules in it (your case). - Package that updates a module and also a package that updates the kernel. You will get the update anyway on both, as the old ones gets updated, and the new one gets installed. - Rebooting into an old kernel without matching userland results in a non-working system (ex. NVIDIA drivers). There is no way you can cover this case. And if you downgrade the matching userland components, anyway you need to rebuild the initrd of all the kernels, and this DKMS configuration covers it. Also, there might be extra modprobe snippets to include in the initrd, besides the modules. Debian rebuilds all initrds by default as well. How would you deal with all of these cases? The only solution is not to include any extra module at all in the initrd, basically every single DKMS package should contain a /usr/lib/dracut.d/ file with an "omit_drivers" line. The recovery should be listing the broken module you are experiencing issues with, by adding "rd.driver.blacklist=module" instead of relying on an old initrd.
What is the module you are having issues with? We're trying to keep track of all the DKMS modules out there in case of breaking changes in DKMS itself.
> What is the module you are having issues with? The module I use is ZFS, but I don't believe it is correct to update/potentially-corrupt the modules in the older/fallback kernels, regardless. > - Package that updates a module and there is more than one kernel installed. Without targeting all kernels, you would get only one initrd updated ... That would be the correct behavior, but adding --regenerate-all breaks the correct behavior. > ... you would get only one initrd updated and then DKMS reporting an updated module for the other kernel but still bundling the old modules in it (your case). Occasionally, when I've run "dkms status" in the past, I would see a parenthesized message along the lines of, "warning, differences between built and installed module". That is what should be displayed for the older kernels after a module has been updated in the latest kernel. Maybe that message only shows if you actually boot into the older kernel. But the correct behavior is to preserve the older kernels as fallback options in case there is a problem with the latest build. You should *never* "burn all your bridges" so that you have no fallback option. Do not update the module in the older kernel trees or initramfses. Those "previously known good" builds should be left untouched. It is perfectly fine for them to be "outdated". They will only be select in case there is a problem with the latest kernel. > - Rebooting into an old kernel without matching userland results in a non-working system (ex. NVIDIA drivers). I would consider that to be a problem with NVIDIA, not the kernel or dkms. NVIDIA drivers should work with slightly older drivers or else fallback to a failsafe mode (e.g. VESA/nomodeset). It is not correct to alter the fallback/last-known-good kernels. There is meant to be some tolerance for differences between userland and the kernel versions. They should not be so closely tied together that you cannot use a pristine/unchanged fallback kernel. I believe there are some efforts to remove all the video drivers from the initramfses. Perhaps that would help to solve this problem with the NVIDIA drivers. But in any case, the fallback kernels must be left untouched -- that is the whole point of having them.