Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: `akmods` refuses to (re)build a module when it thinks the existing module is "up to date". But in some use cases, such as signing the (previously unsigned) modules using `akmods`, the kernel version and module version both will look like they are "up to date", however we need them rebuilt.
I'm -1 for trying to fix user screw-ups within akmods, you already have tools to remove the dud akmod build using dnf or rpm.
I got your point. But as you can see on the Internet, many users use `akmods --force` to "rebuild" modules thinking that parameter will work. Isn't that necessary to add a simple "rebuild" command line argument? It's just a few lines of change and will be very helpful, using dnf or rpm is not really a straight-forward solution to most of us (who will think of uninstalling a specific rpm package to make akmods rebuild a module?)
Would you look at to implement that --rebuild option ? (or fix --force to do what you expect).
@kwizart Sure, I have already done that on my own machine. Let me know where to submit the code.
(In reply to jm33 from comment #4) > @kwizart Sure, I have already done that on my own machine. Let me > know where to submit the code. https://src.fedoraproject.org/rpms/akmods/pull-requests
Hello, Looking at 'man akmods': --force -- try all, even if they failed earlier This seems to say that akmods will try to rebuild all packages modules that failed earlier. Looking at the akmods shell script implementation of the --force commutator, akmods try to rebuild all modules that failed earlier and only the ones that akmods has produced a /var/cache/akmods/module_name/module_version-for-kernel_version.failed.log file for. There is no mechanism to look at each previously successfully build compressed binary module (.ko.xz) or packages and see if it has been intentionally or not unsigned for secure boot or something else, precisely because it has been build successfully. But, if they don't mind, users can easily type in a root console: modinfo the_module_that_was_not_signed_and_the_admin_suspects_it This will print them in the 'filename' field of the response the path to the filename of the module for the running kernel. It will also show the fields 'sig_id', 'signer' and some other fields 'sig*' that can help to know if the module was signed or not. In case the module wasn't signed and the user's goal is to sign it (how to determine this goal programmatically), one can use this command in a console: rpm -qf the_filename_field_content_of_the_modinfo_command This will print the rpm package name that was used to install the non signed module. With this response, one can now remove that rpm package in a root console: dnf remove the_package_name And then launch the 'akmods --force' command. But as you can see, assuming that --force option signifies that akmods have to rebuild an already successful build and installed package, even if it wasn't signed, is nearly impossible to strongly determine for sure, and one reason for that is it's impossible to know if the unsigned process was intentional or was a failing process. Only the user/admin of the machine can know such a thing and be sure this particular module need to be rebuild and/or signed. One last thing. Users can relatively easily automate themself the process described above. Here is as an example, a quick and dirty helper shell script (not tested and provided as is): #!/bin/bash THE_MODULE=$1 if [ "x${THE_MODULE}" != "x" ] ; then THE_FILE=$(modinfo ${THE_MODULE} | grep filename | awk '{print $2}') THE_PACKAGE=$(rpm -qf "${THE_FILE}") dnf -y remove ${THE_PACKAGE} akmods --force else echo "Please add the module name as a parameter to the command line." exit 1 fi exit 0 But, as already said, this is the responsibility of the machine user/admin to monitor and initiate this process. Hope this will help. Cordially, -- NVieville
or you remove kmod and rebuild it again is easy rpm -qa | grep ^kmod- dnf remove kmod-VirtualBox-5.19.15-101.fc35.x86_64 -y akmods
``` diff --git a/akmods b/usr/sbin/akmods index 3706d84..c7bb3ff 100755 --- a/akmods +++ b/usr/sbin/akmods @@ -304,18 +304,12 @@ buildinstall_kmod() # dnf/yum install - repository disabled on purpose see rfbz#3350 akmods_echo 1 4 "Installing newly built rpms" - pkg_mgr=dnf - if [[ -f /usr/bin/dnf ]]; then + if [[ -f /usr/bin/dnf ]] ; then akmods_echo 1 4 "DNF detected" + dnf -y install --disablerepo='*' $(find "${tmpdir}results" -type f -name '*.rpm' | grep -v debuginfo) >> "${kmodlogfile}" 2>&1 else akmods_echo 1 4 "DNF not found, using YUM instead." - pkg_mgr=yum - fi - # if --rebuild is specified, the rpm package should be REinstalled - if [[ ! -n "${rebuild}" ]]; then - "$pkg_mgr" -y install --disablerepo='*' $(find "${tmpdir}results" -type f -name '*.rpm' | grep -v debuginfo) >>"${kmodlogfile}" 2>&1 - else - "$pkg_mgr" -y reinstall --disablerepo='*' $(find "${tmpdir}results" -type f -name '*.rpm' | grep -v debuginfo) >>"${kmodlogfile}" 2>&1 + yum -y install --disablerepo='*' $(find "${tmpdir}results" -type f -name '*.rpm' | grep -v debuginfo) >> "${kmodlogfile}" 2>&1 fi local returncode=$? @@ -346,11 +340,6 @@ buildinstall_kmod() check_kmod_up2date() { - # with --rebuild we should always build - if [[ -n "${rebuild}" ]]; then - return 1 - fi - local this_kernelver=${1} local this_kmodname=${2} local kmodpackage_file="$(modinfo ${this_kmodname} -k ${this_kernelver} -n 2>/dev/null)" @@ -482,7 +471,6 @@ myprog_help () echo $'\n'"Usage: ${myprog} [OPTIONS]" echo $'\n'"Options:" echo " --force -- try all, even if they failed earlier" - echo " --rebuild -- rebuild all, even if they are up to date" echo " --kernels <kernel> -- build and install only for kernel <kernel>" echo " (formatted the same as 'uname -r' would produce)" echo " --akmod <akmod> -- build and install only akmod <akmod>" @@ -539,10 +527,6 @@ while [ "${1}" ] ; do alwaystry=true shift ;; - --rebuild) - rebuild=true - shift - ;; --from-init) # just in case: remove stale lockfile if it exists: rm -f /var/cache/akmods/.lockfile ``` @kwizart I couldn't fork the repo as it requires me to "sign the FPCA" (which redirects to account homepage). Anyway, here is my patch, please check if it can be applied.
Created attachment 1922651 [details] Add --rebuild option to akmods
I think you shoudn't duplicate the dnf/yum install line at all, but create a variable and switch the --install or --reinstall values as appropriate instead...
Why can't you sign the FPCA ? You will need to create an account, indeed, why is that an issue ?
> You will need to create an account Yes I am aware of that, but even after I signed the FPCA, it still asks me to sign it. > but create a variable and switch the --install or --reinstall values as appropriate instead Sure, I will update the script. @kwizart
> I think you shouldn't duplicate the dnf/yum install line at all Sorry but I just read the code, I didn't duplicate the install lines, I used `rebuild` switch to jump to --install/--reinstall commands, the code before my modification has a check for `dnf` binary, which I kept, but replaced with `pkg_mgr` variable to simplify the code. @kwizart
Sorry, but this isn't clear on your commit, can you solve the pagure issue so we can have a proper review/ patch submittion Thanks in advance. (also please don't assign needinfo for any reply)
Sorry for the spam (this is my first bug report), but can you be more specific about what I should do? Like where can I find the "pagure issue"? I am unable to fork the repo on https://src.fedoraproject.org/ as it asks me to sign FCPA when I have already signed (there must be a bug in its account system).
You probably need to be added to one group in order to use pagure... You don't have any group at this time....
See the current WIP version: https://src.fedoraproject.org/rpms/akmods/pull-request/15
This message is a reminder that Fedora Linux 36 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '36'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 36 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
FEDORA-2023-edbc6478d6 has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-edbc6478d6
FEDORA-2023-edbc6478d6 has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.