Description of problem: With current version of akmods, the /var/cache/akmods directory can be huge Version-Release number of selected component (if applicable): current How reproducible: always Steps to Reproduce: 1. install akmods Actual results: After some time the /var/cache/akmods populates and can be huge Expected results: There is expectation to clean-up this directory. Additional info: https://bugzilla.rpmfusion.org/show_bug.cgi?id=4786#c8
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle. Changing version to '28'.
Still on 29.
Hello, As first attempt to respond to this issue, and in parallel of the WIP in https://bugzilla.redhat.com/show_bug.cgi?id=1454824, it should be possible to add in the kmodtool script, when adding %postun sections, these two lines (see WIP for %{package_kmod_name} macro value): rm -f /var/cache/akmods/${kmodname}/%{package_kmod_name}-%{version}-%{release}%{?dist}.$(arch).* > /dev/null || : rm -f /var/cache/akmods/${kmodname}/%{version}-%{release}-for-${kernel_uname_r}.* > /dev/null || : A less surgical way would be to replace the above proposition in the same %postun sections by: rm -f /var/cache/akmods/${kmodname}/*${kernel_uname_r}* > /dev/null || : These two propositions would erase the files (rpm package and log file) generated when building one kmod-module package for one kernel when removing this package, but would not remove all the obsolete files generated before this modification. To clean-up the /var/cache/akmods directory, it would be possible to do something like that (in one line): rm -f $(ls /var/cache/akmods/*/* | grep -v "$(ls -I "*rescue*" /boot/vmlinuz-* | sed 's%.*vmlinuz-%%g')") As this one line command only works for Fedora (RHEL modules in WIP aren't named the same way), here is a shell script part that take care to keep logs and rpm file that are already installed: for one_file in $(ls /var/cache/akmods/*/* | \ grep -v "$(ls -I "*rescue*" /boot/vmlinuz-* | \ sed 's%.*vmlinuz-%%g')") do { if $(grep -qE ".*\.rpm$" <<< "${one_file}") ; then if ! $(rpm -q "$(basename ${one_file%.rpm})" >/dev/null) ; then rm -f "${one_file}" fi else rm -f "${one_file}" fi } Maybe it would be possible to add it in the akmods script at the --from-init case while parsing command line options? This option is used by akmods.service or akmodsinit SysVinit script. Maybe this method (removing all but installed packages related things) is too much aggressive? Any comments are welcome. Cordially, -- NVieville
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. 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 Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 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, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This message is a reminder that Fedora 30 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26. 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 Fedora 'version' of '30'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 30 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, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle. Changing version to 33.
If I understand this correctly you have fixed this in the fork with https://src.fedoraproject.org/fork/nvieville/rpms/akmods/c/191f6dd350b01c682400939e63b061a8d097686e?branch=secure_boot_key_features . I think this caused following error to appear: Oct 18 19:54:19 merceditas systemd[1]: Starting Builds and install new kmods from akmod packages... Oct 18 19:54:19 merceditas akmods[1603]: ls: cannot access '/var/cache/akmods/*/*': No such file or directory Directory itself is present it just doesn't have any subdirectories: # ls -1 /var/cache/akmods/ | wc -l 0
(In reply to scroolik from comment #8) > If I understand this correctly you have fixed this in the fork with > https://src.fedoraproject.org/fork/nvieville/rpms/akmods/c/ > 191f6dd350b01c682400939e63b061a8d097686e?branch=secure_boot_key_features . I > think this caused following error to appear: > > Oct 18 19:54:19 merceditas systemd[1]: Starting Builds and install new kmods > from akmod packages... > Oct 18 19:54:19 merceditas akmods[1603]: ls: cannot access > '/var/cache/akmods/*/*': No such file or directory > > Directory itself is present it just doesn't have any subdirectories: > > # ls -1 /var/cache/akmods/ | wc -l > 0 Hello, Thanks for reporting this issue. It should be fixed with https://src.fedoraproject.org/fork/nvieville/rpms/akmods/c/44bc2332ad60f47619fc7f1d1c0f5729fea478d8?branch=secure_boot_key_features. Tests are welcome. Please feel free to make any comment about this subject. Cordially, -- NVieville
This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. 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 Fedora 'version' of '33'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 33 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, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
should be fixed with https://src.fedoraproject.org/rpms/akmods/c/9e9bef27968eae604cdf22b41f4b385697418e46?branch=rawhide
This bug appears to have been reported against 'rawhide' during the Fedora 36 development cycle. Changing version to 36.
We are using logrotate for the log, but not cleaning the content of the cache directory. We should probably only keep the content on request.
(In reply to Nicolas Chauvet (kwizart) from comment #15) > We are using logrotate for the log, but not cleaning the content of the > cache directory. > > We should probably only keep the content on request. One precision: the cleaning of the content of /var/cache/akmods directory is done by akmods itself. Since commit #9e9bef2 of akmods main branch, the cleaning of the cache directory is done by dropping all the build rpms files and their respective logs for which there is no kernel. Thought it would be useful to point this out. Cordially, -- NVieville
(In reply to nicolas.vieville from comment #16) > (In reply to Nicolas Chauvet (kwizart) from comment #15) ... > > We should probably only keep the content on request. > > One precision: the cleaning of the content of /var/cache/akmods directory ... Thanks for this precision. So this bug can be closed.