Hi David, thank you for you fast answer > -----Ursprüngliche Nachricht----- > Von: David Kalnischkies [mailto:david@kalnischkies.de] > Gesendet: Dienstag, 23. März 2021 11:19 > An: Schulz, Reiner <R.Schulz@dvz-mv.de>; 985771@bugs.debian.org > Betreff: Re: Bug#985771: apt-auto-removal isn't run by kernel update > > On Tue, Mar 23, 2021 at 10:18:34AM +0100, Reiner Schulz wrote: > > On 5 of our Debian 10 Server the separate /boot Partition filled up with old > kernels > > on a few Server without separate /boot partition are up to 10 old kernel left > > > > I check if linux-image\* was marked "manual", there where a few on some > Server, but not on all. > > (Those marked manual will never be removed) [RS] I know, so i did: apt-mark auto linux-image\* > > /etc/kernel/postinst.d/apt-auto-removal should remove all old kernels but the > last two > > (the logic is slightly more complex than this) [RS] its looks like. > > /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 > > -- 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 > 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 > On a sidenote: Debian 11 will ship with a rework of this kernel removing > more tightly integrated into apt directly. I am inclined to declare this > "fixed" in >= 2.1.16 hence, but lets see first if that is something > which could affect those versions, too (and is something not working "as > designed"). [RS] it would good to find a way to handle this, as we need months to upgrade to Debain 11
Attachment:
01autoremove-kernels
Description: 01autoremove-kernels