Using apt full-upgrade is also useful to avoid filling up your /boot with kernel images and initrds. A simple apt upgrade will not remove packages and thus not clean up old kernel images. If you want to keep track of Debian unstable, then you indeed should be using apt full-upgrade.
5 Likes
Does it delete all of them? Would this make it harder to recover if e.g. a new kernel doesn’t boot?
Is that very different than doing an “apt autoremove” after updating?
1 Like
apt will keep the following kernels:
- the one you currently have booted
- the installed kernel with the highest version
- the installed kernel with the second-highest version
- kernel packages that are not marked as automatically installed
Thus, even if your system is running for a very long time and you are performing more than one kernel upgrade in that time and if the new kernel happens to be broken and if you did not manually mark a previously installed kernel as manually installed, you will still be able to boot into the kernel you had running before you rebooted, because apt will keep the kernel that you were running at the time that you ran “apt autoremove” or “apt full-upgrade”.
Reading apt’s source code, running “apt autoremove” seems to be performing the same kernel cleanup as “apt full-upgrade”. Please somebody correct me if you see something different happening in practice.
To prevent a package from being autoremoved, you can always mark it as manually installed. This is what also happens with packages that you manually “apt install”. In case of kernel packages, they usually get installed because linux-image-mnt-reform-arm64 gets upgraded and the new version then depends on a new linux-image-X.Y.Z-mnt-reform-arm64 package. Since you do not manually install linux-image-X.Y.Z-mnt-reform-arm64 but since it is pulled in as a dependency of another package, it is marked as being “automatically” installed. And those packages are candidates for autoremoval. To mark a package as manually installed and thus prevent apt from automatically removing them with “apt autoremove” or “apt full-upgrade”, use the “apt-mark” tool, and for example run:
apt-mark manual linux-image-X.Y.Z-mnt-reform-arm64
2 Likes
I was confused by this since I still seem to be running out of space on /boot, despite only using full-upgrade now. I occasionally get
Processing triggers for initramfs-tools (0.148.2) ...
update-initramfs: Generating /boot/initrd.img-6.15.3-mnt-reform-arm64
cpio: write error: No space left on device
E: mkinitramfs failure uncompressed cpio 2
update-initramfs: failed for /boot/initrd.img-6.15.3-mnt-reform-arm64 with 1.
dpkg: error processing package initramfs-tools (--configure):
installed initramfs-tools package post-installation script subprocess returned error exit status 1
in the past I solved this by running autoremove and update-initramfs manually (I think?). This is after full-upgrade, autoremove, reboot, autoremove:
$ dpkg -l 'linux-image*' | grep '^ii'
ii linux-image-6.10.9-mnt-reform-arm64 6.10.9-1+reform20240916T143123Z arm64 Linux 6.10 for 64-bit ARMv8 machines (MNT Reform)
ii linux-image-6.12.20-mnt-reform-arm64 6.12.20-1+reform20250323T000715Z arm64 Linux 6.12 for 64-bit ARMv8 machines (MNT Reform)
ii linux-image-6.12.21-mnt-reform-arm64 6.12.21-1+reform20250403T221306Z arm64 Linux 6.12 for 64-bit ARMv8 machines (MNT Reform)
ii linux-image-6.12.22-mnt-reform-arm64 6.12.22-1+reform20250412T175526Z arm64 Linux 6.12 for 64-bit ARMv8 machines (MNT Reform)
ii linux-image-6.14.5-mnt-reform-arm64 6.14.5-1~exp1+reform20250508T045900Z arm64 Linux 6.14 for 64-bit ARMv8 machines (MNT Reform)
ii linux-image-6.14.6-mnt-reform-arm64 6.14.6-1~exp1+reform20250528T152822Z arm64 Linux 6.14 for 64-bit ARMv8 machines (MNT Reform)
ii linux-image-6.15.3-mnt-reform-arm64 6.15.3-1~exp1+reform20250624T140900Z arm64 Linux 6.15 for 64-bit ARMv8 machines (MNT Reform)
ii linux-image-mnt-reform-arm64 6.15.3-1~exp1+reform20250624T140900Z arm64 Linux for 64-bit ARMv8 machines (MNT Reform) (meta-package)
I had to move some out of /boot to be able to upgrade. The total size of just the initrds and vmlinuzs alone is uncomfortably close for my 488M /boot partition :
$ du -ch /boot/initrd* /boot/vmlinuz* extra-boot/initrd* extra-boot/vmlinuz-*
35M /boot/initrd.img-6.12.21-mnt-reform-arm64
35M /boot/initrd.img-6.12.22-mnt-reform-arm64
35M /boot/initrd.img-6.14.5-mnt-reform-arm64
35M /boot/initrd.img-6.14.6-mnt-reform-arm64
36M /boot/initrd.img-6.15.3-mnt-reform-arm64
30M /boot/vmlinuz-6.12.21-mnt-reform-arm64
30M /boot/vmlinuz-6.12.22-mnt-reform-arm64
34M /boot/vmlinuz-6.14.5-mnt-reform-arm64
34M /boot/vmlinuz-6.14.6-mnt-reform-arm64
35M /boot/vmlinuz-6.15.3-mnt-reform-arm64
34M extra-boot/initrd.img-6.10.9-mnt-reform-arm64
35M extra-boot/initrd.img-6.12.20-mnt-reform-arm64
28M extra-boot/vmlinuz-6.10.9-mnt-reform-arm64
30M extra-boot/vmlinuz-6.12.20-mnt-reform-arm64
458M total
Wondering if anyone has thoughts: is apt holding onto too many kernels now, did I overspecify versions to install, or is my /boot just too small for current kernels (since it seems like they’re trending bigger)?
I don’t know if apt autoclean would affect this, but it’s something I run periodically after apt full-upgrade and apt autoremove runs.
I don’t think autoclean affects /boot (from man apt-get)
Like clean, autoclean clears out the local repository of retrieved package files. The difference is that it only removes package files that can no
longer be downloaded, and are largely useless. This allows a cache to be maintained over a long period without it growing out of control. The
configuration option APT::Clean-Installed will prevent installed packages from being erased if it is set to off.
1 Like
It would be interesting to see this for your system. On my system I get this when running apt-mark:
[josch@reform] ~ % apt-mark showauto | grep linux-image
linux-image-6.10.6+bpo-mnt-reform-arm64
linux-image-6.11.5+bpo-mnt-reform-arm64
linux-image-6.12.9+bpo-mnt-reform-arm64
[josch@reform] ~ % apt-mark showmanual | grep linux-image
linux-image-mnt-reform-arm64
Interesting, I bet I did this by accident when I was messing with the flickering issue:
$ apt-mark showmanual | grep linux-image
linux-image-6.12.21-mnt-reform-arm64
linux-image-6.12.22-mnt-reform-arm64
linux-image-6.14.5-mnt-reform-arm64
linux-image-mnt-reform-arm64
$ apt-mark showauto | grep linux-image
linux-image-6.14.6-mnt-reform-arm64
linux-image-6.15.3-mnt-reform-arm64
$ dpkg -l 'linux-image*' | grep '^ii'
ii linux-image-6.12.21-mnt-reform-arm64 6.12.21-1+reform20250403T221306Z arm64 Linux 6.12 for 64-bit ARMv8 machines (MNT Reform)
ii linux-image-6.12.22-mnt-reform-arm64 6.12.22-1+reform20250412T175526Z arm64 Linux 6.12 for 64-bit ARMv8 machines (MNT Reform)
ii linux-image-6.14.5-mnt-reform-arm64 6.14.5-1~exp1+reform20250508T045900Z arm64 Linux 6.14 for 64-bit ARMv8 machines (MNT Reform)
ii linux-image-6.14.6-mnt-reform-arm64 6.14.6-1~exp1+reform20250528T152822Z arm64 Linux 6.14 for 64-bit ARMv8 machines (MNT Reform)
ii linux-image-6.15.3-mnt-reform-arm64 6.15.3-1~exp1+reform20250624T140900Z arm64 Linux 6.15 for 64-bit ARMv8 machines (MNT Reform)
ii linux-image-mnt-reform-arm64 6.15.3-1~exp1+reform20250624T140900Z arm64 Linux for 64-bit ARMv8 machines (MNT Reform) (meta-package)
(I removed 6.12.20 and 6.10.9 manually before seeing this message)