Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #92145 > unrolled thread

Bug#1135141: please be more careful with available disk space on /boot

Back to article view | Back to linux.debian.kernel

Contents

  Bug#1135141: please be more careful with available disk space on /boot Harald Dunkel <harri@afaics.de> - 2026-04-28 10:00 +0200
    Bug#1135141: please be more careful with available disk space on /boot Ben Hutchings <ben@decadent.org.uk> - 2026-04-28 12:30 +0200
      Bug#1135141: please be more careful with available disk space on /boot Ben Hutchings <ben@decadent.org.uk> - 2026-04-29 22:10 +0200
    Processed: Re: Bug#1135141: please be more careful with available  disk space on /boot "Debian Bug Tracking System" <owner@bugs.debian.org> - 2026-04-28 12:30 +0200
      Re: Processed: Re: Bug#1135141: please be more careful with available  disk space on /boot Harald Dunkel <harri@afaics.de> - 2026-05-24 16:50 +0200

#92145 — Bug#1135141: please be more careful with available disk space on /boot

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. 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

[toc] | [next] | [standalone]

#92147

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#92166

[Multipart message — attachments visible in raw view] — view raw

On Tue, 2026-04-28 at 12:18 +0200, Ben Hutchings wrote:
[...]
> 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?
[...]

Also which filesystem is used for /boot?

Ben.

-- 
Ben Hutchings
One of the nice things about standards is that
there are so many of them.

[toc] | [prev] | [next] | [standalone]

#92148 — Processed: Re: Bug#1135141: please be more careful with available disk space on /boot

Processing control commands:

> tag -1 moreinfo
Bug #1135141 [initramfs-tools] please be more careful with available disk space on /boot
Added tag(s) moreinfo.

-- 
1135141: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1135141
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#92742 — Re: Processed: Re: Bug#1135141: please be more careful with available disk space on /boot

Sorry for the delay.

- /boot is ext4.
- I have no idea how the image got corrupted. I have seen this
   only once.

 >> AFAICT the new initrd.img is constructed on /boot, while
 >> the previous initrd is still in place.
 >
 > That is intentional and not a bug.

I think I understood where the 3rd image is stored: In /var/tmp/\
initramfs.XXXXXXX. If /boot is not a dedicated partition, then disk
space is shared between /var/tmp and /boot, increasing the risk for
a full disk at update-initramfs runtime.

Regards
Harri

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web