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

Re: disk usage for /usr/lib on bullseye

On Fri 05 May 2023 at 14:35:08 (+0000), Bonno Bloksma wrote:
> As I was trying to find out what would work and if I was doing something wrong getting rid of old kernels....
> After upgrading a new kernel for a week I will do apt autoremove to get rid of the old kernel(s).

And this will produce the situation you have with 16 and 17:

  linutr:/usr/lib/modules# du * -sh
  4.7M    5.10.0-16-amd64
  4.7M    5.10.0-17-amd64
  309M    5.10.0-18-amd64
  309M    5.10.0-19-amd64
  309M    5.10.0-20-amd64
  309M    5.10.0-21-amd64

You need to run   apt --purge autoremove   in order to remove the
files that aren't in the linux-package that you installed. Look:

  $ ls -Glg /lib/modules/5.10.0-21-amd64/ 
  total 4968
  drwxr-xr-x 12    4096 Jan 23 21:45 kernel
  -rw-r--r--  1 1241172 Jan 23 21:46 modules.alias
  -rw-r--r--  1 1187730 Jan 23 21:46 modules.alias.bin
  -rw-r--r--  1    5541 Jan 21 08:35 modules.builtin
  -rw-r--r--  1       0 Jan 23 21:46 modules.builtin.alias.bin
  -rw-r--r--  1    6754 Jan 23 21:46 modules.builtin.bin
  -rw-r--r--  1   38430 Jan 21 08:35 modules.builtin.modinfo
  -rw-r--r--  1  498055 Jan 23 21:46 modules.dep
  -rw-r--r--  1  671751 Jan 23 21:46 modules.dep.bin
  -rw-r--r--  1     476 Jan 23 21:46 modules.devname
  -rw-r--r--  1  154011 Jan 21 08:35 modules.order
  -rw-r--r--  1    1067 Jan 23 21:46 modules.softdep
  -rw-r--r--  1  562879 Jan 23 21:46 modules.symbols
  -rw-r--r--  1  685618 Jan 23 21:46 modules.symbols.bin

apt (auto)remove   only removes the package files, dated Jan 21.
The ones here dated Jan 23 were generated when the package was
installed, and are only removed when you /purge/ the package.

> Debian will automatically keep the current kernel and the previous in the /boot folder.
> Somehow, I get the feeling there either is a bug which causes the /usr/lib/modules/ folder not to be cleaned up or there are somehow links to it from packages that were updated when a specific kernel was active.

> But.... is this a bug in the cleanup of an old kernel or are there realy links to the old modules, links that are now broken?
> If it s a bug, who will report it? I know only enough to report the symptoms.

Someone who demonstrates it. AFAICT you don't seem to be aware of
the --purge option and the necessity of using it here, and have
likely just forgotten to even run apt autoremove in the case of
versions 18 and 19 above (where the modules are also present).

On Fri 05 May 2023 at 11:54:55 (-0400), Greg Wooledge wrote:
> On Fri, May 05, 2023 at 02:35:08PM +0000, Bonno Bloksma wrote:
> > Just created a snapshot of my servers and then did:
[ … ]
> It seems like you're just trying random commands without understanding
> what they do.

Agreed. It makes you wonder how much in this thread that was written
about these commands has been absorbed.

> > I am now cleaning some by hand. Running kernel -22 and having -21 as backup kernel I did:
> > xxxxx:/usr/lib/modules# rm -rd 5.10.0-16-amd64/
> > xxxxx:/usr/lib/modules# rm -rd 5.10.0-17-amd64/
> > xxxxx:/usr/lib/modules# rm -rd 5.10.0-18-amd64/
> One imagines that if you simply purged all of the kernel packages that
> had been autoremoved, this would clean up the modules.  But I'm not
> 100% sure about that.  If you've got modules that were built by dkms
> for example, I don't know whether those would be removed.

Custom modules would remain, and the rest of the directory tree
removed. This is confirmed by the postrm script, which disposes
of the equivalents to those files dated Jan 23 above.

  if [ "$1" = purge ]; then
      for extra_file in modules.dep modules.isapnpmap modules.pcimap \
                        modules.usbmap modules.parportmap \
                        modules.generic_string modules.ieee1394map \
                        modules.ieee1394map modules.pnpbiosmap \
                        modules.alias modules.ccwmap modules.inputmap \
                        modules.symbols modules.ofmap \
                        modules.seriomap modules.\*.bin \
                        modules.softdep modules.devname; do
          eval rm -f /lib/modules/$version/$extra_file
      rmdir /lib/modules/$version || true

> It would be nice to know whether you had to do this "rm -r" because the
> "dpkg --purge linux-image-5.10.0-16-amd64" failed to remove the modules,
> or whether you simply did not KNOW to try the dpkg --purge first.

I don't think dpkg had yet been suggested as a solution, but it would
do just the same thing, because that is what APT itself uses of course.
Again, custom files would remain, with the usual

  dpkg: warning: while removing x, directory 'y' not empty so not removed

message as a reminder.


Reply to: