But when installing a new kmod version and a new kernel version in a single dnf upgrade, the default DKMS post transaction dracut --regenerate-all --force command fails due to missing folders:
Executing post-transaction command
# command: dracut --regenerate-all --force
dracut[F]: Can't write to /boot/efi/1eeff051ec8246a89c845ef144d9c1f9/6.12.0-124.38.1.el10_1.x86_64: Directory /boot/efi/1eeff051ec8246a89c845ef144d9c1f9/6.12.0-124.38.1.el10_1.x86_64 does not exist or is not accessible.
# exit code: 1
# elapsed time: 00:01:14
----------------------------------------------------------------
After the DKMS scriptlet, everything dnf did run successfully.
For context, here’s the rpm spec:
%global debug_package %{nil}
%global dkms_name led-class-multicolor
%undefine dkms_depends
%global dkms_location /kernel/drivers/leds
Name: kmod-%{dkms_name}-dkms
Version: 6.12.0
Release: 124.38.1%{?dist}
%global dkms_version %{VERSION}-%{RELEASE}
Summary: %{dkms_name} for EL 10
License: GPL-2.0
URL: https://kernel.org
BuildArch: noarch
Requires: dkms
%if 0%{?dkms_depends:1}
Requires: kmod-%{dkms_depends}-dkms >= %{VERSION}-%{RELEASE}
%endif
Source0: %{dkms_name}.tar.xz
Source1: dkms.conf.in
%description
This package provides the %{dkms_name} kernel module,
which is in-tree but not shipped by Red Hat.
%prep
%autosetup -c
cp %{SOURCE1} dkms.conf
sed -i -e 's/@NAME@/%{dkms_name}/g' dkms.conf
sed -i -e 's/@VERSION@/%{dkms_version}/g' dkms.conf
sed -i -e 's/@MODULE_NAME@/%{dkms_name}/g' dkms.conf
%if 0%{?dkms_depends:1}
sed -i -e 's/@MODULE_DEPENDS@/%{dkms_depends}/g' dkms.conf
sed -i -e 's|@SYMBOLS@|KBUILD_EXTRA_SYMBOLS=${dkms_tree}/%{dkms_depends}/%{VERSION}-%{RELEASE}/${kernelver}/${arch}/module/Module.symvers|g' dkms.conf
%else
sed -i -e '/@MODULE_DEPENDS@/d' dkms.conf
sed -i -e '/@SYMBOLS@/d' dkms.conf
%endif
sed -i -e 's|@MODULE_LOCATION@|%{dkms_location}|g' dkms.conf
%build
%install
mkdir -p %{buildroot}%{_usrsrc}/%{dkms_name}-%{dkms_version}/
cp -r * %{buildroot}%{_usrsrc}/%{dkms_name}-%{dkms_version}/
%post
dkms add -m %{dkms_name} -v %{dkms_version} --rpm_safe_upgrade
dkms install -m %{dkms_name} -v %{dkms_version} --force
%preun
dkms remove -m %{dkms_name} -v %{dkms_version} --all --rpm_safe_upgrade
%files
%license LICENSE
%{_usrsrc}/%{dkms_name}-%{dkms_version}
%changelog
That dracut --regenerate-all --force command should not be run. It was added to work around some problem between NVIDIA drivers and the Linux kernel.[1]
Try creating a /etc/dkms/framework.conf.d/override.conf file containing the following line and see if that fixes the problem.
post_transaction=""
With the above modification, DKMS should apply updates only to the new kernel being installed. It should not try to modify all the installed kernels (or rather, their initramfs images their kernel modules). Updating only the newest kernel was the old, working behavior before that NVIDIA workaround was applied.
I suspect the error you are seeing is DKMS trying to modify a kernel that has already been removed from your system.
The opposite actually, it’s trying to modify a kernel that hasn’t been fully installed yet. Kernel scriptlets executed afterwards, DKMS autoinstall tried to install the modules again and succeeded, but leaving an error dangling like that isn’t good practice.
Hmm, that’s right, DKMS should only be building the kernel objects that are (ultimately) stored under /lib/modules. It should not be messing with things under /boot/efi. That is Dracut’s domain and Dracut runs at a later stage.
$ ls -1 /usr/lib/kernel/install.d
40-dkms.install
50-depmod.install
50-dracut.install
90-loaderentry.install
90-uki-copy.install
92-tuned.install
I’d say that something else is fundamentally wrong with the DKMS module you are running. It is attempting to modify files that it should not be modifying.
EDIT: Never mind, I see. It is that post_transaction=... line. In your case, it is trying to call Dracut too early (I think).
Well, I don’t know anything about what it is you are working on, but if you are trying to do things with the initramfs, that should be done in a Dracut module. DKMS should “stay in its lane” and just build the modules.
Is your DKMS module exiting with a return code of 0? DKMS was changed quite some time ago such that any non-zero exit code (other than 77) will halt the whole build process.[1] Prior to that change, DKMS had a “continue on error” behavior where a DKMS module that returned a non-zero status would not affect anything else. The initramfs would just get built without the module that failed to build.
The command ran by DKMS failed, likely because it ran before the scriptlets of a new kernel since dracut reported directory does not exist. Everything dnf works as expected. No issue if I run it manually afterwards.
…maybe it’s dependency issue? Without explicit dependency dnf executed the scriptlets in arbitrary order?
This looks like a race condition and could be one of the reasons for suppressing the errors:
DKMS must be triggered for each new/old kernel/module install/remove operation, so failing the earlier trigger does not really matter as long as the later one succeeds.
