Unless you can come with a solution, I'm more willing to delete the akmods-shutdown script completely. 
I don't get why this is still here and it unsupported mechanism.

It's not the fault of akmods.. 
 
Thanks to you, mentioning that it's a script, I took a look and the script is fine, it's the kernels package fault.

Today i have this different output:


# akmods-shutdown 
Building modules for all installed kernels.
Checking kmods exist for 6.8.11-200.fc39.x86_64            [  OK  ]
Checking kmods exist for 6.9.5-100.fc39.x86_64             [  OK  ]
Kernel 6.8.8-100.fc38.x86_64 not installed
Kernel 6.8.9-100.fc38.x86_64 not installed
Checking kmods exist for 6.9.4-100.fc39.x86_64             [  OK  ]
Checking kmods exist for 6.9.5-100.fc39.x86_64             [  OK  ]
Checking kmods exist for 6.9.5-100.fc39.x86_64             [  OK  ]


because, the old kernel packages did not delete theire directories proper:

[root@eve ~]# ls -ls /usr/src/kernels/
insgesamt 20
4 drwxr-xr-x. 25 root root 4096 22. Jun 10:02 6.8.11-200.fc39.x86_64
4 drwxr-xr-x. 25 root root 4096 10. Mai 10:02 6.8.8-100.fc38.x86_64
4 drwxr-xr-x. 25 root root 4096 10. Mai 10:01 6.8.9-100.fc38.x86_64
4 drwxr-xr-x. 25 root root 4096 22. Jun 10:02 6.9.4-100.fc39.x86_64
4 drwxr-xr-x. 25 root root 4096 22. Jun 10:02 6.9.5-100.fc39.x86_64

All the script does it, going throu the list of kernels and call the build procedure and a wrong fully assumption, that the content of /u/s/kernels if ok, which it is clearly not.

kernel-core-6.8.11-200.fc39.x86_64
kernel-core-6.9.4-100.fc39.x86_64
kernel-core-6.9.5-100.fc39.x86_64

I switch the component of this bugreport over to the kernel team which can invest theire post-uninstall script and/or give it the rpm team.

@Nicolas kwizart:

The mentioned triple naming of the new default kernel is caused by this:


init ()
...
        if ! $(echo "${kernels}" | grep -q "${default_kernel}") ; then
                kernels="${kernels} ${default_kernel}"
        fi

it wrongfully adds the default kernel to the list of kernels to check, even if one explicit kernel is given with --kernels options to akmods. 

the argument loop also contains a mistake:

                        # overwrites the default:
                        if [[ ! -n "${kernels}" ]] ; then
                                kernels="${1}"
                        else 
                                kernels="${kernels} ${1}"
                        fi

This code runs before init() is called, which should set "the default" it shall overwrite there. 

Simple fix: move init() before the argument parser loop.

/usr/sbin/akmods

Line 604 a.f.
+# Call INIT to INIT the defaults, that are overwritten in the argument parser!
+init
+
+
# first parse command line options
while [ "${1}" ] ; do

...

# sanity checks
- init
+# init


Proof of Fix:

[root@eve kernels]# /usr/sbin/akmods --kernels 6.9.4-100.fc39.x86_64
Checking kmods exist for 6.9.4-100.fc39.x86_64             [  OK  ]
Checking kmods exist for 6.9.5-100.fc39.x86_64             [  OK  ]
Checking kmods exist for 6.9.4-100.fc39.x86_64             [  OK  ]


@kernelTeam: That does not explain why f38 kernels have been left over in /usr/src/kernels
But i have my feelings this caused all the trouble:

https://bugzilla.redhat.com/show_bug.cgi?id=2280808

Thanks for the fix. I've push your change into the akmods package (that is the upstream, there is no separate official git remote for this component)

I will push an update for f39+ hopefully in a few...

Note: this "init move" seems to have caused a regression in the way akmods checks for permissions. (akmods --help now requires perm to access /boot/grub2/grubenv)

I will need to revisit...

So if I understand correctly, when the --kernels is given, we end in the situation where the same value can be taken from:
- kernels=$(uname -r) 
- default_kernel
- parsed --kernel parameters

Now I don't get why init() would override any default since the default value is empty (kernels= at line44)  and init() should only override to uname -r if no value are parsed. (so if kernels remains empty).

That been said /usr/sbin/akmods --kernels "$(uname -r)" only shows one kernel in my case:
sudo akmods --kernels $(uname -r)
Checking kmods exist for 6.10.5-200.fc40.x86_64

So I'm not reproducing...

FEDORA-2024-de149af836 (akmods-0.5.10-1.fc42) has been submitted as an update to Fedora 42.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-de149af836

FEDORA-2024-de149af836 (akmods-0.5.10-1.fc42) has been pushed to the Fedora 42 stable repository.
If problem still persists, please make note of it in this bug report.

okay, it seems akmods-shutdown is broken beyound repair

# akmods-shutdown 
Building modules for all installed kernels.
/usr/sbin/akmods --kernels 5.17.3-300.fc36.x86_64
/usr/sbin/akmods --kernels 5.17.3-302.fc36.x86_64
/usr/sbin/akmods --kernels 5.17.5-300.fc36.x86_64
/usr/sbin/akmods --kernels 6.10.4-200.fc40.x86_64
/usr/sbin/akmods --kernels 6.10.5-200.fc40.x86_64
/usr/sbin/akmods --kernels 6.9.10-200.fc40.x86_64

Now It may lead to akmods breaking on kernels without any kernel-devel installed (or even, known broken kernel that will fails the kmod).

If one wants to run on shutdown, I will switch the akmod-shutdown.service to default to use akmod instead.

FEDORA-2024-b68cf9dd25 (akmods-0.5.10-6.fc41) has been submitted as an update to Fedora 41.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-b68cf9dd25

FEDORA-2024-b68cf9dd25 (akmods-0.5.10-6.fc41) has been pushed to the Fedora 41 stable repository.
If problem still persists, please make note of it in this bug report.