Using update-initramfs -k all -c:

AFAICT the new initrd.img is constructed on /boot, while
the previous initrd is still in place. There is a high
risk of filling up all disk space, esp since zstd creates
a 3rd image at run time. If you are not careful, you
might end up with an error message at boot time, saying

initramfs unpacking failed: ZSTD-compressed data is corrupt

I would suggest to create the new initrd either on a
dedicated tmpfs or in /tmp, to move it to /boot as a final
step. You could check in advance if there is enough disk
space to hold the new initrd, and you would avoid temporary
data on /boot, making better use of the available disk
space.


Just a suggestion, of course.

Regards
Harri

Control: tag -1 moreinfo

That is intentional and not a bug.

This is the real problem and is difficult to solve.  It can't be solved
in initramfs-tools alone.

The compressor runs as part of a pipeline.  No intermediate files are
created in /boot.

I would very much like to know how that happened.  update-initramfs
creates the new image under a temporary name and then renames it over
the old image (on success) or deletes it (on failure).  So it should not
be possible for the boot loader to pick up an incomplete image.

Do you have any log or other information about the sequence of events
leading to this?

What problem does that solve?  The copy can also be interrupted and
truncated.

As explained, there are no intermediate files on /boot.  There can be 1
incomplete new image, but that is necessary for atomically (so far as
possible) replacing images.

If there is not enough disk space to hold the new image, update-
initramfs must fail.  I don't see the value of trying to detect that
failure very slightly earlier.

Ben.

On Tue, 2026-04-28 at 12:18 +0200, Ben Hutchings wrote:
[...]
[...]

Also which filesystem is used for /boot?

Ben.

Forwarding Harri's reply to the BTS: