While running 'apt updata' followed by 'apt upgrade' this morning I
got the following error from dpkg:-

...
...
Processing triggers for initramfs-tools (0.148.3) ...
update-initramfs: Generating /boot/initrd.img-6.12.63+deb13-amd64
zstd: error 70 : Write error : cannot write block : No space left on device
E: mkinitramfs failure cpio 141
E: mkinitramfs failure zstd -q -9 -T0 70
update-initramfs: failed for /boot/initrd.img-6.12.63+deb13-amd64 with 1.
dpkg: error processing package initramfs-tools (--configure):
installed initramfs-tools package post-installation script subprocess returned error exit status 1
Processing triggers for hicolor-icon-theme (0.18-2) ...
Processing triggers for cups (2.4.10-3+deb13u2) ...
Errors were encountered while processing:
initramfs-tools
Error: Sub-process /usr/bin/dpkg returned an error code (1)
...
...

I can't see any obvious lack of space on any of the 'real' disk drives:-

Filesystem Type 1M-blocks Used Avail Use% Mounted on
/dev/mapper/t470--vg-root ext4 936644 201503 687490 23% /
efivarfs efivarfs 1 1 1 56% /sys/firmware/efi/efivars
/dev/sda1 ext4 960331 18776 892702 3% /bak
/dev/nvme0n1p2 ext2 456 264 168 62% /boot
/dev/nvme0n1p1 vfat 511 5 507 1% /boot/efi

Even if I include tmpfs I can't see much wrong:-
Filesystem 1M-blocks Used Available Use% Mounted on
udev 3797 0 3797 0% /dev
tmpfs 772 2 770 1% /run
/dev/mapper/t470--vg-root 936644 201503 687490 23% /
tmpfs 3856 57 3800 2% /dev/shm
efivarfs 1 1 1 56% /sys/firmware/efi/efivars
tmpfs 5 1 5 1% /run/lock
/dev/sda1 960331 18776 892702 3% /bak
/dev/nvme0n1p2 456 264 168 62% /boot
tmpfs 3856 74 3782 2% /tmp
/dev/nvme0n1p1 511 5 507 1% /boot/efi
tmpfs 1 0 1 0% /run/credentials/getty@tty1.service
tmpfs 772 1 772 1% /run/user/1000
tmpfs 1 0 1 0% /run/credentials/systemd-journald.service

The upgrade appeared to complete OK but it would still be good to know
what the 'No space' error was about.

Any ideas anyone?

--
Chris Green
ú

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Mon, 12 Jan 2026, Chris Green wrote:

While running 'apt updata' followed by 'apt upgrade' this morning I
got the following error from dpkg:-

...
...
Processing triggers for initramfs-tools (0.148.3) ...
update-initramfs: Generating /boot/initrd.img-6.12.63+deb13-amd64
zstd: error 70 : Write error : cannot write block : No space left on device
E: mkinitramfs failure cpio 141
E: mkinitramfs failure zstd -q -9 -T0 70
update-initramfs: failed for /boot/initrd.img-6.12.63+deb13-amd64 with 1.
dpkg: error processing package initramfs-tools (--configure):
installed initramfs-tools package post-installation script subprocess returned error exit status 1
Processing triggers for hicolor-icon-theme (0.18-2) ...
Processing triggers for cups (2.4.10-3+deb13u2) ...
Errors were encountered while processing:
initramfs-tools
Error: Sub-process /usr/bin/dpkg returned an error code (1)
...
...

I can't see any obvious lack of space on any of the 'real' disk drives:-

Filesystem Type 1M-blocks Used Avail Use% Mounted on
/dev/mapper/t470--vg-root ext4 936644 201503 687490 23% /
efivarfs efivarfs 1 1 1 56% /sys/firmware/efi/efivars
/dev/sda1 ext4 960331 18776 892702 3% /bak
/dev/nvme0n1p2 ext2 456 264 168 62% /boot
/dev/nvme0n1p1 vfat 511 5 507 1% /boot/efi

/var (/) or /boot are the two usual culprits. /var looks ample to hold
the uncompressed initrd so I'd guess /boot. Look at how big your
existing initrd is, you'll need at least that much space.

Setting modules=dep in initrd.conf (writing from memory so that might
not be correct) will likely get you past this (I'm guessing you have modules=most)

Tim.

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

12.01.26, 11:05 +0100, Chris Green:

While running 'apt updata' followed by 'apt upgrade' this morning I
got the following error from dpkg:-

...
...
Processing triggers for initramfs-tools (0.148.3) ...
update-initramfs: Generating /boot/initrd.img-6.12.63+deb13-amd64
zstd: error 70 : Write error : cannot write block : No space left on device

May be that your /boot device is too small.

/dev/nvme0n1p2 ext2 456 264 168 62% /boot

168M might not be enough.

https://www.debian.org/releases/trixie/release-notes/issues.html#ensure-boot-has-enough-free-space

The upgrade appeared to complete OK but it would still be good to know
what the 'No space' error was about.

You should check if the initrd.img really was created/updated. WRT the
error message above, it probably wasn't.

--
Regards
mks

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-01-12, Chris Green wrote:

I can't see any obvious lack of space on any of the 'real' disk drives:-

Filesystem Type 1M-blocks Used Avail Use% Mounted on
/dev/mapper/t470--vg-root ext4 936644 201503 687490 23% /
efivarfs efivarfs 1 1 1 56% /sys/firmware/efi/efivars
/dev/sda1 ext4 960331 18776 892702 3% /bak
/dev/nvme0n1p2 ext2 456 264 168 62% /boot
/dev/nvme0n1p1 vfat 511 5 507 1% /boot/efi

The error seems to be triggered during building initramfs. It is build in /boot. If you have much drivers used the initramfs can use more than 168M
for its compression via zstd. If you can't enlarge /dev/nvme0n1p2 you
could remove older kernels installed and/or limit the drivers
used.

Check if you have in /etc/initramfs-tools/initramfs.conf
MODULES=dep
BUSYBOX=auto
In case they are not, change them and rebuild with
update-initramfs -u -k all

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Mon, Jan 12, 2026 at 5:20?AM Chris Green <cl@isbd.net> wrote:

While running 'apt updata' followed by 'apt upgrade' this morning I
got the following error from dpkg:-

...
...
Processing triggers for initramfs-tools (0.148.3) ...
update-initramfs: Generating /boot/initrd.img-6.12.63+deb13-amd64
zstd: error 70 : Write error : cannot write block : No space left on

device

E: mkinitramfs failure cpio 141
E: mkinitramfs failure zstd -q -9 -T0 70
update-initramfs: failed for /boot/initrd.img-6.12.63+deb13-amd64 wit

h 1.

dpkg: error processing package initramfs-tools (--configure):
installed initramfs-tools package post-installation script subproces

s returned error exit status 1

Processing triggers for hicolor-icon-theme (0.18-2) ...
Processing triggers for cups (2.4.10-3+deb13u2) ...
Errors were encountered while processing:
initramfs-tools
Error: Sub-process /usr/bin/dpkg returned an error code (1)
...
...

I can't see any obvious lack of space on any of the 'real' disk drives:-

Filesystem Type 1M-blocks Used Avail Use% Mount

ed on

/dev/mapper/t470--vg-root ext4 936644 201503 687490 23% /
efivarfs efivarfs 1 1 1 56% /sys/

firmware/efi/efivars

/dev/sda1 ext4 960331 18776 892702 3% /bak
/dev/nvme0n1p2 ext2 456 264 168 62% /boot
/dev/nvme0n1p1 vfat 511 5 507 1% /boot

/efi

Even if I include tmpfs I can't see much wrong:-
Filesystem 1M-blocks Used Available Use% Mounted on
udev 3797 0 3797 0% /dev
tmpfs 772 2 770 1% /run
/dev/mapper/t470--vg-root 936644 201503 687490 23% /
tmpfs 3856 57 3800 2% /dev/shm
efivarfs 1 1 1 56% /sys/firmwa

re/efi/efivars

tmpfs 5 1 5 1% /run/lock
/dev/sda1 960331 18776 892702 3% /bak
/dev/nvme0n1p2 456 264 168 62% /boot
tmpfs 3856 74 3782 2% /tmp
/dev/nvme0n1p1 511 5 507 1% /boot/efi
tmpfs 1 0 1 0% /run/creden

tials/getty@tty1.service

tmpfs 772 1 772 1% /run/user/1

000

tmpfs 1 0 1 0% /run/creden

tials/systemd-journald.service

The upgrade appeared to complete OK but it would still be good to know
what the 'No space' error was about.

Any ideas anyone?

My guess is, /boot is full.

Also see <https://www.debian.org/releases/trixie/release-notes/issues.html# ensure-boot-has-enough-free-space>.

Jeff

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Markus Sch”nhaber <debian-user@list-post.mks-mail.de> writes:

May be that your /boot device is too small.

/dev/nvme0n1p2 ext2 456 264 168 62% /boot

168M might not be enough.

The Debian installer creates (or at least created in past versions)
/boot which is too small by default to contain three kernel versions
(with default initramfs.conf). So unless you do "apt autoremove" or
manually delete the oldest kernel before upgrading, you very likely run
out of space.

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Henrik Ahlgren <pablo@seestieto.com> wrote:

Markus Sch”nhaber <debian-user@list-post.mks-mail.de> writes:

May be that your /boot device is too small.

/dev/nvme0n1p2 ext2 456 264 168 62% /boot

168M might not be enough.

The Debian installer creates (or at least created in past versions)
/boot which is too small by default to contain three kernel versions
(with default initramfs.conf). So unless you do "apt autoremove" or
manually delete the oldest kernel before upgrading, you very likely run
out of space.

Yes, it does seem likely that the size of /boot is the culprit.
There are currently (as is normal) just two kernel versions in /boot
and nothing much else of significance.

I assume therefore that the slow increase in kernel size has finally
caused this issue.

What's the most straightforward way to increase the size of /boot?
There's **loads** of disk space available but since /boot is a
separate partition I guess I need to run gparted or some such from a
USB stick to shrink the / partition and grow /boot a bit.

Why is /boot a separate partition? On my other trixie system (not
EFI) everything is just one partition. Both systems were installed
'from scratch' and I just let the installer do default partitioning.
Does EFI really need to be so much more complicated?

--
Chris Green
ú

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Hi,

On Mon, Jan 12, 2026 at 01:47:47PM +0000, Chris Green wrote:

What's the most straightforward way to increase the size of /boot?
There's **loads** of disk space available but since /boot is a
separate partition I guess I need to run gparted or some such from a
USB stick to shrink the / partition and grow /boot a bit.

It looks like your root filesystem is on LVM so that should be fairly
trivial (other than the need to boot into a live system) to shrink.

Is your partition for /boot adjacent to that though? What is the actual
layout of your nvme0n1?

Why is /boot a separate partition? On my other trixie system (not
EFI) everything is just one partition. Both systems were installed
'from scratch' and I just let the installer do default partitioning.
Does EFI really need to be so much more complicated?

Not usually no. I can't speak of what the installer does by default, so
I don't doubt what you say, it's just that I always do it manually.

Possibly it;s because you put root on LVM, it is being cautious and
putting /boot outside of that? No need for that these days as Grub
can understand LVM, but maybe that is why it chose to do that.

In general it is best to use as few partitions as possible and LVM, and
change things as needed later. You are half way there, but for this
issue with /boot!

Thanks,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Mon, Jan 12, 2026 at 8:50?AM Chris Green <cl@isbd.net> wrote:

[...]
Why is /boot a separate partition? On my other trixie system (not
EFI) everything is just one partition. Both systems were installed
'from scratch' and I just let the installer do default partitioning.
Does EFI really need to be so much more complicated?

In the old days (like 20 years ago), /boot was a separate partition to
arrange its physical location on the drive. /boot needed to be near
the beginning of the drive so grub could load properly, or grub could
load the kernel properly. Drive geometry had something to do with it,
and I believe Cylinder-Head-Sector (CHS) played a big part of it,
before linear addressing of large drives was ubiquitous.

Nowadays, on EFI systems, /boot could be a separate partition because
the EFI spec says the system partition is fat32. Some folks make
/boot fat32, while other folks make /boot/efi fat32.

My guess is your two Trixie systems have different configurations
because one is a MBR system, and one is an EFI system.

(A lot of this has mostly faded from my memory, so corrections, please).

Jeff

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Jeffrey Walton <noloader@gmail.com> wrote:

On Mon, Jan 12, 2026 at 8:50?AM Chris Green <cl@isbd.net> wrote:

[...]
Why is /boot a separate partition? On my other trixie system (not
EFI) everything is just one partition. Both systems were installed
'from scratch' and I just let the installer do default partitioning.
Does EFI really need to be so much more complicated?

In the old days (like 20 years ago), /boot was a separate partition to arrange its physical location on the drive. /boot needed to be near
the beginning of the drive so grub could load properly, or grub could
load the kernel properly. Drive geometry had something to do with it,
and I believe Cylinder-Head-Sector (CHS) played a big part of it,
before linear addressing of large drives was ubiquitous.

Nowadays, on EFI systems, /boot could be a separate partition because
the EFI spec says the system partition is fat32. Some folks make
/boot fat32, while other folks make /boot/efi fat32.

My guess is your two Trixie systems have different configurations
because one is a MBR system, and one is an EFI system.

Yes, that's probably right. As I said I just let the installer provide
a 'standard' installation on both systems and ended up with a
different disk layout on each.

Anyway I created a gparted USB stick this afternoon and used it to
reduce the main (/) partition's size by 1.5Gb and added the resulting
extra space to the /boot partition. It took a **long** time to move
the 1Tb / partition along a bit (several hours) but it all worked very
smoothly and I now have lots of spare space in /boot.

--
Chris Green
ú

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Chris Green <cl@isbd.net> writes:

Anyway I created a gparted USB stick this afternoon and used it to
reduce the main (/) partition's size by 1.5Gb and added the resulting
extra space to the /boot partition. It took a **long** time to move
the 1Tb / partition along a bit (several hours) but it all worked very smoothly and I now have lots of spare space in /boot.

Well, good for you. I would've booted boot since what's the point? It
can just as well be a directory off / and /boot/efi can be the requisite
FAT partition. Especially as I at least usually have some largish rescue
iso like GRML in /boot as well. Don't need to fish around for some USB
stick for partition surgery when the rescue system is right there on the
SSD. And GRML makes it easy, there's a Debian package which generates a
GRUB entry to boot the ISO directly.

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Mon, 2026-01-12 at 19:30 +0000, Chris Green wrote:

Jeffrey Walton <noloader@gmail.com> wrote:

On Mon, Jan 12, 2026 at 8:50?AM Chris Green <cl@isbd.net> wrote

:

[...]
Why is /boot a separate partition?ÿ On my other trixie system
(not EFI) everything is just one partition.ÿ Both systems were
installed 'from scratch' and I just let the installer do default partitioning.
Does EFI really need to be so much more complicated?

Anyway I created a gparted USB stick this afternoon and used it to
reduce the main (/) partition's size by 1.5Gb and added the resulting
extra space to the /boot partition.ÿ It took a **long** time to move
the 1Tb / partition along a bit (several hours) but it all worked
very smoothly and I now have lots of spare space in /boot.

For a next time, it's probably easier (and certainly much faster) to
just move /boot and its contents to the main partition and stop
mounting the former /boot partition there.

(And when using LVM you could then also add its space to an existing
partition, but otherwise it's also not a lot of space lost...)


--
Jan Claeys

(please don't CC me when replying to the list)

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Anssi Saari <anssi.saari@debian-user.mail.kapsi.fi> wrote:

Chris Green <cl@isbd.net> writes:

Anyway I created a gparted USB stick this afternoon and used it to
reduce the main (/) partition's size by 1.5Gb and added the resulting
extra space to the /boot partition. It took a **long** time to move
the 1Tb / partition along a bit (several hours) but it all worked very smoothly and I now have lots of spare space in /boot.

Well, good for you. I would've booted boot since what's the point? It
can just as well be a directory off / and /boot/efi can be the requisite
FAT partition. Especially as I at least usually have some largish rescue
iso like GRML in /boot as well. Don't need to fish around for some USB
stick for partition surgery when the rescue system is right there on the
SSD. And GRML makes it easy, there's a Debian package which generates a
GRUB entry to boot the ISO directly.

Yes, ideally I would have liked to get rid of the separate /boot
partition but the reality was that moving things around a bit with
gparted was more straightforward.

Next clean installation I will try and get rid of the separate /boot.

--
Chris Green
ú

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-01-12, Andy Smith <andy@strugglers.net> wrote:

Why is /boot a separate partition? On my other trixie system (not
EFI) everything is just one partition. Both systems were installed
'from scratch' and I just let the installer do default partitioning.
Does EFI really need to be so much more complicated?

Not usually no. I can't speak of what the installer does by default, so
I don't doubt what you say, it's just that I always do it manually.

I used to take the defaults because I was afraid of manual partitioning
(in those bygone years when you had to worry about "sectors" and all
that jazz), but Debian would give you a tiny root partition (if you
asked for a separate home partition, which I always did).

These days, though, when partitioning manually, it's easy as pie: you can
enter a percentage as a value and you're good to go.

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Recovery environment (was: Out of space error from dpkg, but I can't see where)

Anssi Saari [2026-01-13 14:37:31] wrote:

[...] Especially as I at least usually have some largish rescue iso
like GRML in /boot as well. Don't need to fish around for some USB
stick for partition surgery when the rescue system is right there on
the SSD. And GRML makes it easy, there's a Debian package which
generates a GRUB entry to boot the ISO directly.

FWIW, in most cases I get away with using the initrd environment,
instead (and if I need a tool that's not in the initrd, I can often
temporarily mount and chroot into the "real" OS).

I wonder if someone has made a Debian package which "formalizes" this
practice (e.g. adds an entry for it to the boot menu, and maybe
makes sure the initrd is not too minimalist).


- Stefan

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)