why does virtualbox keep all my old /lib/modules directories around?

[Robert P. J. Day]

  not sure why i never noticed this before, but even though updating
my fedora box keeps only the last three versions of the kernel, i have
a couple dozen /lib/modules directories each representing an older
version of the kernel going back to 4.11.12, and when i examine all
those old directories, they contain nothing but:

4.11.12-200.fc25.x86_64
│   └── misc
│       ├── vboxdrv.ko
│       ├── vboxnetadp.ko
│       ├── vboxnetflt.ko
│       └── vboxpci.ko

... etc etc ...

  i'm sure i'm safe to manually remove all those older /lib/modules,
but should i be surprised that they're even there? is there something
i can configure about virtualbox to not have it lock those old
directories in place?

rday

[Ed Greshko]

On 02/24/18 15:32, Robert P. J. Day wrote:
>    not sure why i never noticed this before, but even though updating
>  my fedora box keeps only the last three versions of the kernel, i have
>  a couple dozen /lib/modules directories each representing an older
>  version of the kernel going back to 4.11.12, and when i examine all
>  those old directories, they contain nothing but:
>
>  4.11.12-200.fc25.x86_64
>  │   └── misc
>  │       ├── vboxdrv.ko
>  │       ├── vboxnetadp.ko
>  │       ├── vboxnetflt.ko
>  │       └── vboxpci.ko
>
>  ... etc etc ...
>
>    i'm sure i'm safe to manually remove all those older /lib/modules,
>  but should i be surprised that they're even there? is there something
>  i can configure about virtualbox to not have it lock those old
>  directories in place? 
Sounds more like the kernel removal process than anything related to virtualbox.

As a test, you could manually remove the oldest of the 3 kernels on your system and
see what that results in.

-- 
A motto of mine is: When in doubt, try it out

[Todd Zullinger]

Ed Greshko wrote:
>  On 02/24/18 15:32, Robert P. J. Day wrote:
> >   not sure why i never noticed this before, but even though updating
> > my fedora box keeps only the last three versions of the kernel, i have
> > a couple dozen /lib/modules directories each representing an older
> > version of the kernel going back to 4.11.12, and when i examine all
> > those old directories, they contain nothing but:
> >
> > 4.11.12-200.fc25.x86_64
> > │   └── misc
> > │       ├── vboxdrv.ko
> > │       ├── vboxnetadp.ko
> > │       ├── vboxnetflt.ko
> > │       └── vboxpci.ko
> >
> > ... etc etc ...
> >
> >   i'm sure i'm safe to manually remove all those older /lib/modules,
> > but should i be surprised that they're even there? is there something
> > i can configure about virtualbox to not have it lock those old
> > directories in place?
>  
>  Sounds more like the kernel removal process than anything related to virtualbox. 
It depends on how the Virtualbox modules are installed.  If
they're via kmod/akmod packages, then when the corresponding
kernel is removed the kmod-vbox-${kernel_uname} package
should be removed, removing the files it installed.

I suspect that the vbox modules weren't installed via an rpm
package -- or if they were, those packages lack a proper
requirement on the kernel version they're built for, which
leaves this cruft.

Running:

  $ rpm -qf /lib/modules/4.11.12-200.fc25.x86_64/misc/vboxdrv.ko

would be useful in determining whether they're owned by any
package.  We know they don't come from the kernel rpm, so
it's not it's job to clean them up (and it would be wrong if
it did, of course).

-- 
Todd
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A fool's brain digests philosophy into folly, science into
superstition, and art into pedantry.  Hence University education.
    -- George Bernard Shaw

[Robert P. J. Day]

On Sat, 24 Feb 2018, Todd Zullinger wrote:

>  Ed Greshko wrote:
>  > On 02/24/18 15:32, Robert P. J. Day wrote:
>  >>   not sure why i never noticed this before, but even though
>  >> updating my fedora box keeps only the last three versions of the
>  >> kernel, i have a couple dozen /lib/modules directories each
>  >> representing an older version of the kernel going back to
>  >> 4.11.12, and when i examine all those old directories, they
>  >> contain nothing but:
>  >>
>  >> 4.11.12-200.fc25.x86_64
>  >> │   └── misc
>  >> │       ├── vboxdrv.ko
>  >> │       ├── vboxnetadp.ko
>  >> │       ├── vboxnetflt.ko
>  >> │       └── vboxpci.ko
>  >>
>  >> ... etc etc ...
>  >>
>  >>   i'm sure i'm safe to manually remove all those older
>  >> /lib/modules, but should i be surprised that they're even there?
>  >> is there something i can configure about virtualbox to not have
>  >> it lock those old directories in place?
>  >
>  > Sounds more like the kernel removal process than anything related
>  > to virtualbox.
>
>  It depends on how the Virtualbox modules are installed.  If they're
>  via kmod/akmod packages, then when the corresponding kernel is
>  removed the kmod-vbox-${kernel_uname} package should be removed,
>  removing the files it installed. 
  i honestly don't recall how they came to be there, but i rarely
install anything on my fedora system *not* via an actual .rpm package.

>  I suspect that the vbox modules weren't installed via an rpm
> package
>  -- or if they were, those packages lack a proper requirement on the
>  kernel version they're built for, which leaves this cruft.
>
>  Running:
>
>    $ rpm -qf /lib/modules/4.11.12-200.fc25.x86_64/misc/vboxdrv.ko
>
>  would be useful in determining whether they're owned by any package.
>  We know they don't come from the kernel rpm, so it's not it's job to
>  clean them up (and it would be wrong if it did, of course). 
  totally predictably:

$ rpm -qf /lib/modules/4.11.12-200.fc25.x86_64/misc/vboxdrv.ko
file /lib/modules/4.11.12-200.fc25.x86_64/misc/vboxdrv.ko is not owned by any package
$

  so, clearly, kernel removal comes along to remove the corresponding
/lib/modules directory, finds it still has content, and is forced to
leave it there. that's annoying. is there any option for kernel
removal to at least warn that it can't delete the /lib/modules
directory? not sure why i never noticed this before, i'll try to
recall how virtualbox ended up on this system.

rday

[Todd Zullinger]

Robert P. J. Day wrote:
>    i honestly don't recall how they came to be there, but i
> rarely
>  install anything on my fedora system *not* via an actual .rpm package. 
I don't know how Virtualbox works, but perhaps some version
in the past installed via rpm and then helpfully compiled
modules for updated kernels and installed those directly --
as opposed to how akmods work by generating a kmod package
and installing that?

>    so, clearly, kernel removal comes along to remove the
> corresponding
>  /lib/modules directory, finds it still has content, and is forced to
>  leave it there. that's annoying. 
But much better than rpm removing directories that are not
empty and contain files which are not part of any package,
of couse. :)

>  is there any option for kernel removal to at least warn
>  that it can't delete the /lib/modules directory? 
I'm not aware of any such options.  That would have to be
done in rpm, I believe.  And then it would likely warn far
more often than you'd want.

You could write a quick script which looked for orphaned
files under /lib/modules (and optionally cleaned them up)
fairly easily.

You do have to be careful to not remove some files generated
by depmod (which kmod packages call in their
%post scriptlets, at least).

Running something like this occasionally should help locate
any cruft:

    find /lib/modules/ ! -name 'modules.*' -print0 | \
        xargs -r0 rpm -qf | awk '/is not owned/ {print $2}'

That's not perfect by any means.  The awk portion is
particularly broken if the listed files contain spaces.  I
don't know of a way to have rpm output only the filename or
use a different separator.

If I was going to really use such a script I'd look at the
python rpm bindings most likely.

Short of that, I'd tighten the unowned filename extraction
in one way or another.  Matching the full line and stripping
out the leading 'file ' and trailing 'is not owned by any
package' is probably the simplest method -- not necessarily
done with awk.  It could be grep piped to sed, perl, or
whatever suits your tastes.

-- 
Todd
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Don't take life seriously, you'll never get out alive.

[Ed Greshko]

On 02/25/18 02:51, Todd Zullinger wrote:
>  Robert P. J. Day wrote:
> >   i honestly don't recall how they came to be there, but i rarely
> > install anything on my fedora system *not* via an actual .rpm package.
>  I don't know how Virtualbox works, but perhaps some version
>  in the past installed via rpm and then helpfully compiled
>  modules for updated kernels and installed those directly --
>  as opposed to how akmods work by generating a kmod package
>  and installing that? 
If one installs VirtualBox packaged by rpmfusion then you get akmod-VirtualBox. 
Other than that, I'm not familiar with the rpmfusion process since I don't use
rpmfusion for VBox.

I use VirtualBox directly from Oracle.  In that case the drivers are built as needed
by the vboxdrv.service.  I don't know about placement of the drivers in the rpmfusion
case, but in the Oracle case they get installed in /lib/modules//`uname -r`/misc. 
This directory does not exist on a kernel that doesn't have VirtualBox installed.

Prior to systemd, I'm pretty sure VirtualBox also used init scripts to determine
if/when the modules needed to be built for a running kernel.

In the recent past I use to get warning messages when running "dnf update" and a
new
kernel was being installed and directories/files were being left undeleted.  At some
point, probably with a new version of dnf, I stopped getting the messages....but I
got so used to them I really didn't take notice.

-- 
A motto of mine is: When in doubt, try it out