On Mon 08 May 2023 at 08:27:52 (+0000), Bonno Bloksma wrote: > > "apt autoremove" will remove (not purge) packages > [....] > Thanks for the better explanation, that is what I understood as well.
I doubt that. > > One imagines that if you simply purged all of the kernel packages that had > > been autoremoved, this would clean up the modules. > Yes, that would seem to be prudent but I also do not understand why the > modules would be left behind? As far as I understand they are the module part > of the kernel. Without the kernel they are useless. Why not treat them as > part of the kernel. When I remove the kernel, remove the modules. In your linams system, used as the example below, you removed, but did not purge, versions 7 through 16. We assume (because you haven't shown us) that the kernel/initrd/config/systemmap have all gone, and we can see that the *modules have also been deleted*. That's why each of those /lib/modules/5.10.0-NN-amd64/ directories only occupies 4.7MB of space rather than 309MB (as listed in your OP). > > 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. > As I use the apt and (apt-get) exclusively for package management I would > like them to clean up what I do not need when I tell it to clean it up. For the sake of brevity, I'm going to assume that you're not compiling custom kernel modules, and so we can put on one side the fact that even purge would not delete them. As for "cleaning up", apt(-get) does just what you instruct it to do. > > 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. > > Look here: Yes, look /carefully/ (at the number of links. That's the number between permissions and owner). > ------<Quote>--------------------- > xxxxxx:~# cd /usr/lib/modules > xxxxxx:/usr/lib/modules# ll > total 56 > drwxr-xr-x 2 root root 4096 Apr 19 2022 5.10.0-10-amd64 > drwxr-xr-x 2 root root 4096 Apr 19 2022 5.10.0-11-amd64 > drwxr-xr-x 2 root root 4096 Jun 17 2022 5.10.0-12-amd64 > drwxr-xr-x 2 root root 4096 Jul 29 2022 5.10.0-13-amd64 > drwxr-xr-x 2 root root 4096 Dec 12 07:40 5.10.0-15-amd64 > drwxr-xr-x 2 root root 4096 Dec 12 07:40 5.10.0-16-amd64 > drwxr-xr-x 3 root root 4096 Sep 17 2022 5.10.0-18-amd64 > drwxr-xr-x 3 root root 4096 Nov 2 2022 5.10.0-19-amd64 > drwxr-xr-x 3 root root 4096 Jan 3 16:51 5.10.0-20-amd64 > drwxr-xr-x 3 root root 4096 Mar 3 09:40 5.10.0-21-amd64 > drwxr-xr-x 3 root root 4096 Apr 29 13:18 5.10.0-22-amd64 > drwxr-xr-x 2 root root 4096 Dec 13 2021 5.10.0-7-amd64 > drwxr-xr-x 2 root root 4096 Jan 24 2022 5.10.0-8-amd64 > drwxr-xr-x 2 root root 4096 Mar 11 2022 5.10.0-9-amd64 > xxxxxx:/usr/lib/modules# dpkg --purge linux-image-5.10.0-7-amd64 > (Reading database ... 57231 files and directories currently installed.) > Purging configuration files for linux-image-5.10.0-7-amd64 (5.10.40-1) ... > xxxxxx:/usr/lib/modules# ll > total 52 > drwxr-xr-x 2 root root 4096 Apr 19 2022 5.10.0-10-amd64 > drwxr-xr-x 2 root root 4096 Apr 19 2022 5.10.0-11-amd64 > drwxr-xr-x 2 root root 4096 Jun 17 2022 5.10.0-12-amd64 > drwxr-xr-x 2 root root 4096 Jul 29 2022 5.10.0-13-amd64 > drwxr-xr-x 2 root root 4096 Dec 12 07:40 5.10.0-15-amd64 > drwxr-xr-x 2 root root 4096 Dec 12 07:40 5.10.0-16-amd64 > drwxr-xr-x 3 root root 4096 Sep 17 2022 5.10.0-18-amd64 > drwxr-xr-x 3 root root 4096 Nov 2 2022 5.10.0-19-amd64 > drwxr-xr-x 3 root root 4096 Jan 3 16:51 5.10.0-20-amd64 > drwxr-xr-x 3 root root 4096 Mar 3 09:40 5.10.0-21-amd64 > drwxr-xr-x 3 root root 4096 Apr 29 13:18 5.10.0-22-amd64 > drwxr-xr-x 2 root root 4096 Jan 24 2022 5.10.0-8-amd64 > drwxr-xr-x 2 root root 4096 Mar 11 2022 5.10.0-9-amd64 > xxxxxx:/usr/lib/modules# > > ------<Quote>--------------------- > > So it seems using the dpkg --purge against the removed kernel version is the > proper way(?) to get rid of the kernels. If you want your 4.7MB (×8) of space back, yes. > But I still think this should be part of the apt autoremove for kernels. No, that's not policy. If "remove" purges, then why bother with having a --purge option at all? > I understand there are circumstances where not al modules assigned to a > kernel version are part of the kernel. But... would they be of any use when > that kernel version is no longer installed? I've already explained exactly what is not deleted by "remove", but requires "purge" as well or instead. I listed the actual files, about ten of them: https://lists.debian.org/debian-user/2023/05/msg00275.html In the listing above, you have removed versions 7 through 16, and then purged 7, as quoted above. The remaining 8 through 16 contain no modules, and the evidence is shown in your listing above: there can be no kernel/ directory in any of them. Debian has put in place some protections for kernels to try to prevent users from making the system unbootable. What Debian isn't going to do is change entirely the APT policy just to suit your reluctance to purge kernels rather than just remove them; viz: remove: removes the files in the package, but not configuration (or other) files that it or you might have installed. purge: removes both the files in the package and the configuration files, including those in the package and those generated at installation time. (In addition, it makes enquiries when files designated as configuration files are detected as having been changed from what was supplied in the package.) Cheers, David.
