On Tue, Mar 23, 2021 at 10:48:37AM +0000, Schulz, Reiner wrote: > > > /etc/kernel/postinst.d/apt-auto-removal isn't run after kernel updates > > > > > > How can i check why? > > > > It probably is, but as it is not producing any output to the console > > there is also no indication given that it was run (technical hint: That > > is a choice being made by the kernel packages, which run the scripts > > with "run-parts --report", which is documented to behave that way). > > [RS] but starting the other scripts is noted in term.log: > > Setting up linux-image-4.19.0-14-amd64 (4.19.171-2) ... > ... > /etc/kernel/postinst.d/initramfs-tools: > update-initramfs: Generating /boot/initrd.img-4.19.0-14-amd64 > ... > /etc/kernel/postinst.d/zz-update-grub: > Generating grub configuration file ... > > Scripts from /etc/kernel/postrm.d/ are also noted (They are noted as they produce output… the line "update-initramfs: Generating /boot/initrd.img-4.19.0-14-amd64" is e.g. produced by the initramfs-tools script. As apt-auto-removal does not produce any output no indication that the following lines are generated by named script is generated, which is what "/etc/kernel/postinst.d/initramfs-tools:" is.) > > > -- Package-specific info: > > […] > > > APT::NeverAutoRemove:: "^linux-image-4\.19\.0-13-amd64$"; > > > APT::NeverAutoRemove:: "^linux-image-4\.19\.0-14-amd64$"; > > […] > > > Kernel: Linux 4.19.0-14-amd64 (SMP w/2 CPU cores) > > > > This looks correct and shows its indeed run as expected. > > [RS] indeed, i run /etc/apt/apt.conf.d/01autoremove-kernels by hand and all looks good > > > Can you perhaps attach the /etc/apt/apt.conf.d/01autoremove-kernels > > file? It it generated by the script and should contain a bunch of debug > > information at the end which could help if the generated config is > > otherwise wrong (but it doesn't look like that). > > [RS] I do This file includes: […] | /* Debug information: | # dpkg list: | rc linux-image-4.19.0-10-amd64 4.19.132-1 amd64 Linux 4.19 for 64-bit PCs (signed) | rc linux-image-4.19.0-11-amd64 4.19.146-1 amd64 Linux 4.19 for 64-bit PCs (signed) | rc linux-image-4.19.0-12-amd64 4.19.152-1 amd64 Linux 4.19 for 64-bit PCs (signed) | ii linux-image-4.19.0-13-amd64 4.19.160-2 amd64 Linux 4.19 for 64-bit PCs (signed) | ii linux-image-4.19.0-14-amd64 4.19.171-2 amd64 Linux 4.19 for 64-bit PCs (signed) | rc linux-image-4.19.0-8-amd64 4.19.98-1+deb10u1 amd64 Linux 4.19 for 64-bit PCs (signed) | rc linux-image-4.19.0-9-amd64 4.19.118-2+deb10u1 amd64 Linux 4.19 for 64-bit PCs (signed) | rc linux-image-4.9.0-12-amd64 4.9.210-1 amd64 Linux 4.9 for 64-bit PCs | rc linux-image-4.9.0-8-amd64 4.9.144-3.1 amd64 Linux 4.9 for 64-bit PCs | ii linux-image-amd64 4.19+105+deb10u9 amd64 Linux for 64-bit PCs (meta-package) so only the last two kernel 4.19.0-13 & -14 are installed, as it should be. The rest are removed and only config files remain (= "rc"). These remaining bits shouldn't take up too much space & you can remove them by calling "apt purge linux-image-…" on those rc packages. In Debian 11 you will be able to call "apt purge ~c" (short for "apt purge ?config-files" – apt-patterns are an apt 2.0 feature, backported and adapted from aptitude; this pattern is available there already in earlier Debian releases in case you want/can use aptitude) to purge all packages which are in the rc state. Perhaps kernel packages should be auto-purged by default? As Julian wrote the last iteration of the kernel removing I will leave that up to him though as there might be reasons for it either way. > > It looks for me more like something depends/recommends those kernel > > packages though. Out of tree modules perhaps? Try "apt remove -s > > linux-image-4.19.0-13-amd64" perhaps that already shows something > > although a bit unlikely (as that would only react on hard dependencies, > > while recommends, or-groups and virtual packages are more likely). > > [RS] 18 of the 23 Servers are virtual machines > And all have the some problem Are the kernel packages on those servers in 'rc' state, too? Or are they shown as ii (fully installed), hi (installed, but on hold) or i and some uppercase letter (various forms of partly installed) ? Best regards David Kalnischkies
Attachment:
signature.asc
Description: PGP signature