[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: disk usage for /usr/lib on bullseye



On Mon 01 May 2023 at 11:06:25 (-0600), Charles Curley wrote:
> On Mon, 1 May 2023 13:51:06 +0000 > Bonno Bloksma wrote:
> 
> > Guessing on what I see these are libraries for older kernel versions.
> > I usually clean up older kernel versions by using # apt autoremove"
> > All 3 servers have 1 older kernel version installed according to apt
> > autoremove.
> 
> Autoremove removes packages, it does not purge. The difference is that
> remove leaves configuration files in place. So you have a tedious bit
> of "apt purge linux-image-… [linux-image-…]" etc. ahead. Just be sure
> to not purge the two most recent kernel packages, and especially not
> the kernel you are currently running on.

The modules aren't configuration files. AFAICT linux-image-*.debs
don't contain any. A small number of module.* files are generated
at installation time, eg modules.dep is probably the best known.

> > Why is this stuff there? Can I delete it?
> > If I can delete it, is there a proper way to clean it up or do I just
> > rm /usr/lib/modules/5.10.0-.... for the older kernels?
> 
> See above.
> 
> I conjecture that the reason updating the kernel removes rather than
> purges old kernels is in case the user has a custom kernel and wishes
> to preserve those customizations.

But if you create custom modules in the modules tree (which
I used to do with ndiswrapper), then they don't appear in
/var/lib/dpkg/info/linux-image-*.md5sums, so they should get
left behind by remove or purge.

The only other files that remove will normally leave behind
are those that are generated at installation time. The
package's postrm script attempts to delete these, and lastly
the /lib/modules/$version/ directory if it is empty.

Cheers,
David.


Reply to: