Dear Maintainer, 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. /etc/kernel/postinst.d/apt-auto-removal should remove all old kernels but the last two I greped over 23 Debian 10 Server: ansible DEBIAN_10 -b -m shell -a 'zgrep 'postinst.d' /var/log/apt/term.log* ' >> grep_term.log 2>&1 grep -c -E 'zz-update-grub' grep_term.log 115 grep -c -E 'initramfs-tools' grep_term.log 138 grep -c -E 'apt-auto-removal' grep_term.log 2 i will attach grep_term.log /etc/kernel/postinst.d/apt-auto-removal isn't run after kernel updates How can i check why?
(Those marked manual will never be removed) (the logic is slightly more complex than this) 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). […] […] 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). 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). 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"). Best regards David Kalnischkies
No... it creates a config file telling apt which kernels to remove _when you run autoremove_. apt 2.2 automatically removes kernels during apt dist-upgrade / apt full-upgrade (not using apt-get). Did you run autoremove? I'm not sure what this is supposed to tell us, the hook is (usually) silent, so it's not going to appear in the terminal output. I don't believe that.
Hi David, thank you for you fast answer [RS] I know, so i did: apt-mark auto linux-image\* [RS] its looks like. [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 [RS] indeed, i run /etc/apt/apt.conf.d/01autoremove-kernels by hand and all looks good [RS] I do [RS] 18 of the 23 Servers are virtual machines And all have the some problem [RS] it would good to find a way to handle this, as we need months to upgrade to Debain 11
[RS] yes, correct, i describe it in a very short way [RS] Do i have to run autoremove regulary? To remove old kernels? [RS] if a new kernel is to setting up, the scripts from /etc/kernel/postinst.d/ are noted: 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 ... So i expected to see there a note for /etc/kernel/postinst.d/apt-auto-removal [RS] i believe you that. I only want to find my mistake, as i deployed all this servers
Don't include that (also starting every paragraph with [RS] is annoying; and your email server is in a rspamd uribl bl.rspamd.com - what's going on there, someone sending spam like crazy?) You have to run autoremove to remove old kernels, yes. Until you use apt 2.2, where apt(8) can autoremove them during dist-upgrade, then you can use that. You need to be careful running autoremove, though, so it's not something you can run automatically. Sometimes yes, but seemingly only when they do output stuff.
I'm sorry OK, i dont know that, thank you for the hint It this behavior dscribed in a man page? OK, thank you for you help. Please close this bug now
(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.) […] | /* 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. 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
ra1183:~# dpkg -l 'linux-image-*' Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-====================================-==================-============-=================================== rc linux-image-3.16.0-4-amd64 3.16.51-3 amd64 Linux 3.16 for 64-bit PCs ii linux-image-4.19.0-10-amd64 4.19.132-1 amd64 Linux 4.19 for 64-bit PCs (signed) un linux-image-4.19.0-10-amd64-unsigned <none> <none> (no description available) ii linux-image-4.19.0-11-amd64 4.19.146-1 amd64 Linux 4.19 for 64-bit PCs (signed) un linux-image-4.19.0-11-amd64-unsigned <none> <none> (no description available) ii linux-image-4.19.0-12-amd64 4.19.152-1 amd64 Linux 4.19 for 64-bit PCs (signed) un linux-image-4.19.0-12-amd64-unsigned <none> <none> (no description available) ii linux-image-4.19.0-13-amd64 4.19.160-2 amd64 Linux 4.19 for 64-bit PCs (signed) un linux-image-4.19.0-13-amd64-unsigned <none> <none> (no description available) ii linux-image-4.19.0-14-amd64 4.19.171-2 amd64 Linux 4.19 for 64-bit PCs (signed) un linux-image-4.19.0-14-amd64-unsigned <none> <none> (no description available) ii linux-image-4.19.0-6-amd64 4.19.67-2+deb10u2 amd64 Linux 4.19 for 64-bit PCs (signed) un linux-image-4.19.0-6-amd64-unsigned <none> <none> (no description available) ii linux-image-4.19.0-8-amd64 4.19.98-1+deb10u1 amd64 Linux 4.19 for 64-bit PCs (signed) un linux-image-4.19.0-8-amd64-unsigned <none> <none> (no description available) ii linux-image-4.19.0-9-amd64 4.19.118-2+deb10u1 amd64 Linux 4.19 for 64-bit PCs (signed) un linux-image-4.19.0-9-amd64-unsigned <none> <none> (no description available) ii linux-image-4.9.0-7-amd64 4.9.110-3+deb9u2 amd64 Linux 4.9 for 64-bit PCs ii linux-image-amd64 4.19+105+deb10u9 amd64 Linux for 64-bit PCs (meta-package) I attached the removal scripts from this server ra1183:~# apt-get -s autoremove Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be REMOVED: linux-image-4.19.0-6-amd64 linux-image-4.19.0-8-amd64 linux-image-4.9.0-7-amd64 0 upgraded, 0 newly installed, 3 to remove and 0 not upgraded. Remv linux-image-4.19.0-6-amd64 [4.19.67-2+deb10u2] Remv linux-image-4.19.0-8-amd64 [4.19.98-1+deb10u1] Remv linux-image-4.9.0-7-amd64 [4.9.110-3+deb9u2] ra1183:~# apt-mark showmanual linux-image-\* linux-image-4.19.0-10-amd64 linux-image-4.19.0-11-amd64 linux-image-4.19.0-12-amd64 linux-image-4.19.0-13-amd64 linux-image-4.19.0-14-amd64 linux-image-4.19.0-9-amd64 linux-image-amd64 ra1183:~# apt-mark showauto linux-image-\* linux-image-4.19.0-6-amd64 linux-image-4.19.0-8-amd64 linux-image-4.9.0-7-amd64 We do our updates via "apt-get -y --with-new-pkgs upgrade <packagelist>" but i cant find a hint if/how this would "mark" the packages
Passing package names to install/upgrade/etc will mark them as manually installed if no other change was made (e.g. if the package is upgradable, it will upgrade them instead; so apt install foo && apt install foo for a package foo might first upgrade foo and the second command will mark it as manual).
OK, many thank for this explanation. you could close this ticket now. Should i open a new Bug to the manpage of apt-get for include this explaintion of "marking" ?