Control: tag -1 moreinfo On Tue, 2026-04-28 at 09:54 +0200, Harald Dunkel wrote: > Package: initramfs-tools > Version: 0.142+deb12u3 > > Using update-initramfs -k all -c: > > AFAICT the new initrd.img is constructed on /boot, while > the previous initrd is still in place.
That is intentional and not a bug. > There is a high risk of filling up all disk space, This is the real problem and is difficult to solve. It can't be solved in initramfs-tools alone. > esp since zstd creates a 3rd image at run time. The compressor runs as part of a pipeline. No intermediate files are created in /boot. > 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 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? > 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. What problem does that solve? The copy can also be interrupted and truncated. > 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. 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. > > Just a suggestion, of course. > > Regards > Harri -- Ben Hutchings Theory and practice are closer in theory than in practice - John Levine
signature.asc
Description: This is a digitally signed message part
