/usr/lib/modules not cleaned up?
Hi, I got a low-space warning on my root folder, and found that /usr/lib/modules is populated back to 5.11.x kernel - Nvidia modules. I wonder if they are not cleaned up when a new kernel is coming? Anything that can be done to automate this? Thanks Axel
On 09/10/2024 12.25, Axel Braun wrote:
I had this problem on systems that rarely reboot. There I have to ocasionally run systemctl restart purge-kernels.service If that does not help, check the 'status' of that service. Maybe you need to touch /boot/do_purge_kernels first? Ciao Bernhard M.
On 10/9/24 12:25 PM, Axel Braun wrote:
NVIDIA modules are indeed not removed. There is probably reason but this should be addressed I think: ~> ls /usr/lib/modules 6.10.11-1-default/ 6.10.3-1-default/ 6.10.5-1-default/ 6.10.8-1-default/ 6.11.0-1-default/ 6.8.1-1-default/ 6.8.4-rc1-1-default/ 6.8.7-1-default/ 6.8.9-1-default/ 6.9.3-1-default/ 6.9.7-1-default/ 6.10.2-1-default/ 6.10.4-1-default/ 6.10.7-1-default/ 6.10.9-1-default/ 6.7.9-1-default/ 6.8.2-1-default/ 6.8.5-1-default/ 6.8.8-1-default/ 6.9.1-1-default/ 6.9.5-1-default/ 6.9.9-1-default/ ~> du -Hs /usr/lib/modules 2.9G /usr/lib/modules
On Wed, Oct 9, 2024 at 1:59 PM Michael Pujos <pujos.michael@gmail.com> wrote:
And why are you surprised? NVIDIA modules are compiled on the end system, the installed files are not tracked by package management in any way. What entity is supposed to remove them and at which moment?
On Wed, Oct 9, 2024 at 3:01 PM Andreas Schwab <schwab@suse.de> wrote:
Currently the same NVIDIA KMP package can be used for any kernel version (providing it still compiles and works). Making binaries %ghost would require a separate package for each kernel build. This is simply unrealistic given the current model. Those packages will be obsolete before they hit the NVIDIA site. If RPM allowed registering additional files as part of the package during installation (as Solaris package management did) it could solve this.
On 10/9/24 1:50 PM, Andrei Borzenkov wrote:
Let's put aside "it's not my problem, it is a NVIDIA problem" for a minute. What about purge-kernels ? It already knows which kernel to purge. It could be extended to remove unneeded modules. Accumulating GBs of obsolete modules in the root partition is not great.
On Wed, Oct 9, 2024 at 3:10 PM Michael Pujos <pujos.michael@gmail.com> wrote:
Except SUSE has such things as weak updates which are linked to binaries from some previous kernel and this previous kernel may be removed, but we do not want it to invalidate weak updates.
It could be extended to remove unneeded modules.
The catch is to detect "unneeded".
Accumulating GBs of obsolete modules in the root partition is not great.
On Wed, Oct 09, 2024 at 12:25:16PM +0200, Axel Braun wrote:
Tried that before, but gave up in the end. :-( For documentation purposes I left in the package: %triggerpostun/kmp-triggerpostun.sh # # Unfortunately doesn't work since kernel updates are not considered "atomar" # when using YaST/zypper (only safe when using rpm) [boo#1182666] # #for dir in $(find /lib/modules -mindepth 1 -maxdepth 1 -type d); do # if [ ! -d $dir/kernel ]; then # test -d $dir/updates && rm -f $dir/updates/nvidia*.ko # fi #done If you want to get rid of the modules in a manual way you can run rpm -e <kmp-package> --nodeps zypper in <kmp-package> because of %postun/kmp-postun.sh if [ "$1" = 0 ] ; then [...] # get rid of *all* nvidia kernel modules when uninstalling package (boo#1180010) for dir in $(find /lib/modules -mindepth 1 -maxdepth 1 -type d); do test -d $dir/updates && rm -f $dir/updates/nvidia*.ko [...] done [...] fi Thanks, Stefan Public Key available ------------------------------------------------------ Stefan Dirsch (Res. & Dev.) SUSE Software Solutions Germany GmbH Tel: 0911-740 53 0 Frankenstraße 146 FAX: 0911-740 53 479 D-90461 Nürnberg http://www.suse.de Germany ---------------------------------------------------------------- Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman (HRB 36809, AG Nürnberg) ----------------------------------------------------------------
On 09/10/2024 12.25, Axel Braun wrote:
I had this problem on systems that rarely reboot. There I have to ocasionally run systemctl restart purge-kernels.service If that does not help, check the 'status' of that service. Maybe you need to touch /boot/do_purge_kernels first? Ciao Bernhard M.
On 10/9/24 12:25 PM, Axel Braun wrote:
NVIDIA modules are indeed not removed. There is probably reason but this should be addressed I think: ~> ls /usr/lib/modules 6.10.11-1-default/ 6.10.3-1-default/ 6.10.5-1-default/ 6.10.8-1-default/ 6.11.0-1-default/ 6.8.1-1-default/ 6.8.4-rc1-1-default/ 6.8.7-1-default/ 6.8.9-1-default/ 6.9.3-1-default/ 6.9.7-1-default/ 6.10.2-1-default/ 6.10.4-1-default/ 6.10.7-1-default/ 6.10.9-1-default/ 6.7.9-1-default/ 6.8.2-1-default/ 6.8.5-1-default/ 6.8.8-1-default/ 6.9.1-1-default/ 6.9.5-1-default/ 6.9.9-1-default/ ~> du -Hs /usr/lib/modules 2.9G /usr/lib/modules
On Wed, Oct 9, 2024 at 1:59 PM Michael Pujos <pujos.michael@gmail.com> wrote:
And why are you surprised? NVIDIA modules are compiled on the end system, the installed files are not tracked by package management in any way. What entity is supposed to remove them and at which moment?
On Wed, Oct 9, 2024 at 3:01 PM Andreas Schwab <schwab@suse.de> wrote:
Currently the same NVIDIA KMP package can be used for any kernel version (providing it still compiles and works). Making binaries %ghost would require a separate package for each kernel build. This is simply unrealistic given the current model. Those packages will be obsolete before they hit the NVIDIA site. If RPM allowed registering additional files as part of the package during installation (as Solaris package management did) it could solve this.
On 10/9/24 1:50 PM, Andrei Borzenkov wrote:
Let's put aside "it's not my problem, it is a NVIDIA problem" for a minute. What about purge-kernels ? It already knows which kernel to purge. It could be extended to remove unneeded modules. Accumulating GBs of obsolete modules in the root partition is not great.
On Wed, Oct 9, 2024 at 3:10 PM Michael Pujos <pujos.michael@gmail.com> wrote:
Except SUSE has such things as weak updates which are linked to binaries from some previous kernel and this previous kernel may be removed, but we do not want it to invalidate weak updates.
It could be extended to remove unneeded modules.
The catch is to detect "unneeded".
Accumulating GBs of obsolete modules in the root partition is not great.
On Wed, Oct 09, 2024 at 12:25:16PM +0200, Axel Braun wrote:
Tried that before, but gave up in the end. :-( For documentation purposes I left in the package: %triggerpostun/kmp-triggerpostun.sh # # Unfortunately doesn't work since kernel updates are not considered "atomar" # when using YaST/zypper (only safe when using rpm) [boo#1182666] # #for dir in $(find /lib/modules -mindepth 1 -maxdepth 1 -type d); do # if [ ! -d $dir/kernel ]; then # test -d $dir/updates && rm -f $dir/updates/nvidia*.ko # fi #done If you want to get rid of the modules in a manual way you can run rpm -e <kmp-package> --nodeps zypper in <kmp-package> because of %postun/kmp-postun.sh if [ "$1" = 0 ] ; then [...] # get rid of *all* nvidia kernel modules when uninstalling package (boo#1180010) for dir in $(find /lib/modules -mindepth 1 -maxdepth 1 -type d); do test -d $dir/updates && rm -f $dir/updates/nvidia*.ko [...] done [...] fi Thanks, Stefan Public Key available ------------------------------------------------------ Stefan Dirsch (Res. & Dev.) SUSE Software Solutions Germany GmbH Tel: 0911-740 53 0 Frankenstraße 146 FAX: 0911-740 53 479 D-90461 Nürnberg http://www.suse.de Germany ---------------------------------------------------------------- Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman (HRB 36809, AG Nürnberg) ----------------------------------------------------------------
participants (6)
-
Andreas Schwab -
Andrei Borzenkov -
Axel Braun -
Bernhard M. Wiedemann -
Michael Pujos -
Stefan Dirsch