3

I do have unattended-upgrades (2.8) installed and the process is running.

Yet it frequently happens that I get this error when trying to install upgrades:

Processing triggers for initramfs-tools (0.140) ...
update-initramfs: Generating /boot/initrd.img-5.10.0-18-amd64
pigz: abort: write error on <stdout> (No space left on device)
E: mkinitramfs failure pigz 28
update-initramfs: failed for /boot/initrd.img-5.10.0-18-amd64 with 1.
dpkg: error processing package initramfs-tools (--configure):
installed initramfs-tools package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
initramfs-tools 

This can be solved by manually removing old kernel images with the command here.

Some background and a solution when removing the kernel images does not work (this happened once) is here and the so far inactive bug report in the completely outdated 1990s style email-based bugtracker for Debian is here.

I'm using Debian 11 with KDE. This has been happening for a long time and has occurred many times now. Why is that (or how to find out)?

If they aren't removed automatically I think the old kernel images should at least be removed, maybe using the command above, when an upgrade fails due to lack of boot-partition disk space.

5
  • I've always assumed that the packaging subsystem doesn't know which kernels are still in use by the grub/initramfs subsystems, so for best safety it doesn't remove old kernels.
    – Sotto Voce
    Sep 30 at 21:25
  • Arch has the reverse problem. It removes the kernel immediately, even if it's still running. Then you can't load modules anymore. You're forced to reboot. So keeping old kernels around is better to avoid breaking the system. But then many wikis, guides, even installers recommend ridiculously small sizes for /boot, while kernel&initramfs images keep growing ever larger. So now you can only barely squeeze 2 kernels where you used to be able to easily fit 10 of them... which increases the pressure on cleanup operations. Haven't used Debian in a while, in Ubuntu autoremove purge seems to work. Sep 30 at 21:58
  • Since mere software cannot know which "old" kernel I might need to boot for testing or other reasons, it leaves the deletion decision to the SysAdmin.
    – waltinator
    Sep 30 at 22:02
  • The command that I linked removes only the kernels that aren't used so it's possible. At the very least once it runs into this problem it should remove these / for example all kernel images except the running and the second newest one. Prompting the user to do so with y/n may be fine too. Concerning the boot partition size - it should work well with small partitions too, especially if there's guides recommending it. I do have a separate and small /boot partition and the disk is fully encrypted. This is very inconvenient, anti-Linux-adoption, irrational, and user-unfriendly.
    – mYnDstrEAm
    Oct 1 at 10:42
  • Related question: askubuntu.com/questions/590673/…
    – mYnDstrEAm
    Oct 6 at 11:41

1 Answer 1

0

As some of the comments note, it's not Debian's job to decide which kernel images you need or don't need. Debian is doing the correct action, preserving your kernel images when it installs new ones, which allows you to boot into a previous version if something went wrong with the newer version. As frostschutz noted in his comment, Arch Linux has the opposite problem, of removing the old kernel image when installing a new one, which is in my experience highly undesirable behavior, though usually it works fine, but not always, particularly when there is a regression in the newer kernel.

This behavior can somewhat vary based on what you want your system to do or not do depending on how you configure it, how you use apt, and what method you use to install new kernels, but I would always, and have always, chosen to keep my previous kernels installed until I remove them explicitly once I've determined that the newer ones work fine, as part of maintaining the system.

However, I believe you are probably using the kernel metapackage on a stable Debian, which is slightly different, I believe that adds a new item to the grub boot list every time it installs an upgraded kernel (like initrd.img-4.15.0-191 to initrd.img-4.15.0-192). So the kernels are packages that are still installed, until you uninstall them. I'd say it's safe to say that Debian expects the system administrator to be aware of simple things like making sure partitions are large enough to do their jobs longer term, and to do scheduled cleanups if partition sizes are an issue.

However, in a sense, this is all totally beside the point, each new image takes up, once installed, maybe 150 MiB or so of space, so the actual issue here is simply that your / is just too small. Or if you are using a separate /boot partition, that's too small. Depends on your setup, you didn't give an relevant details, but that's the main issue.

You can generally use apt autoremove to remove old packages not used anymore, so that might be the simplest solution for you, to just script in that to run daily or weekly or whatever makes sense.

Checking my /boot, the initrd.img, System.map, and vmlinux- files are about 22 MiB for each set, a remote server is about 55 MiB for each set of 3 files, which is not very big, which would suggest your /boot is simply way too small, but that depends on what your / and or /boot look like, and if it's a separate partition.

If you don't have any control over your environment, or if you can't resize the partitions to be something more useful long term, apt autoremove run nightly is probably your best bet, after the automated upgrade runs. Or apt-get autoremove if the Debian is older.

Checking a few remote servers, I noticed a tendency to have the current kernel, and 2 previous ones, but I don't know what does that cleanup action, if it's a setting or configuration you can make with apt, or if it's a scripted solution that just runs nightly. It's definitely not done manually.

I also agree with frostschutz when he notes that online directions for sizing /boot if separate partition suggest tiny sizes that make no sense when you have often terabytes of storage, but you didn't list any specs of the system so that's just guessing. In general you want to post relevant information to your issue when you post a question since otherwise people have to guess.

If you are planning on running the system long term, then you want at least 2x the used capacity in /, 3 to 4x is better, since / contents always get bigger over time. And if separate /boot, then just do the math of how much each kernel will take up, assume each iteration will get about 10% bigger give or take over time, then how many kernels you want to keep active, and that would determine how big your /boot should be if separate. With overhead added on to be on the safe side.

Also, you want to run apt-get clean after each update, of course, otherwise /var/cache/apt fills up with old packages.

2
  • 2
    The OP mentions that unattended-upgrades is installed, and that is supposed to remove old kernels — it keeps the running kernel, and the two newest kernels. Oct 1 at 7:03
  • Oh, that explains the 3 installed kernels I saw on some server instances, thanks. Doesn't explain the issue, maybe it's an old Debian, but no further information was given, required to know: size of /, size of /boot if separate, and Debian release.
    – Lizardx
    Oct 1 at 18:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.