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
done
rmdir /lib/modules/$version || true
fi
> 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.
Cheers,
David.
