CU 201: No space left on device

larsen · 6 May 2026 14:44

On updating from CU 200 to CU 201, I got an error message in /var/log/pakfire/update-core-upgrade-201.log:

dracut[I]: Executing: /usr/bin/dracut --kver=6.18.7-ipfire --force
dracut[I]: *** Including module: modsign ***
dracut[I]: *** Including module: i18n ***
dracut[I]: *** Including module: btrfs ***
dracut[I]: *** Including module: dm ***
dracut[I]: *** Including module: fs-lib ***
dracut[I]: *** Including module: kernel-modules ***
dracut[I]: *** Including module: kernel-modules-extra ***
dracut[I]: *** Including module: lvm ***
dracut[I]: *** Including module: mdraid ***
dracut[I]: *** Including module: qemu ***
dracut[I]: *** Including module: rootfs-block ***
dracut[I]: *** Including module: terminfo ***
dracut[I]: *** Including module: udev-rules ***
dracut[I]: *** Including module: initqueue ***
dracut[I]: *** Including module: base ***
dracut[I]: *** Including modules done ***
dracut[I]: *** Installing kernel module dependencies ***
dracut[I]: *** Installing kernel module dependencies done ***
dracut[I]: *** Resolving executable dependencies ***
dracut[I]: *** Resolving executable dependencies done ***
dracut[I]: *** Generating early-microcode cpio image ***
dracut[I]: *** Constructing AuthenticAMD.bin ***
dracut[I]: *** Constructing GenuineIntel.bin ***
dracut[I]: *** Store current command line parameters ***
dracut[I]: *** Creating image file '/boot/initramfs-6.18.7-ipfire.img.tmp' ***
dracut[I]: *** Hardlinking files ***
dracut[I]: *** Hardlinking files done ***
cp: error writing '/boot/initramfs-6.18.7-ipfire.img.tmp': No space left on device
dracut[F]: Creation of /boot/initramfs-6.18.7-ipfire.img.tmp failed
Generating grub configuration file ...
Found background: /boot/grub/splash.png
Found linux image: /boot/vmlinuz-6.18.7-ipfire
Found initrd image: /boot/initramfs-6.18.7-ipfire.img
Adding boot menu entry for UEFI Firmware Settings ...
Root filesystem isn't btrfs, skipping...
done

Afterwards, /boot has 26 Mb free as before the update. So, only the creation of that tmp file is having a problem (btw: wouldn’t it be possible to create that file on / and move it to /boot afterwards?).

# df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        890M  4.0K  890M   1% /dev
tmpfs           919M     0  919M   0% /dev/shm
tmpfs           919M  772K  918M   1% /run
/dev/sda4        29G  2.7G   25G  10% /
/dev/sda1       110M   76M   26M  75% /boot
/dev/sda2        32M  278K   32M   1% /boot/efi
/var/lock       8.0M   12K  8.0M   1% /var/lock
none            919M   62M  858M   7% /var/log/rrd
none            919M  300K  919M   1% /var/log/vnstat

# ll /boot
total 67M
-rw-r--r-- 1 root root 200K Feb 24 15:03 config-6.18.7-ipfire
drwxr-xr-x 3 root root  16K Jan  1  1970 efi
drwxr-xr-x 6 root root 4.0K May  6 16:29 grub
-rw------- 1 root root  51M Mar 11 17:19 initramfs-6.18.7-ipfire.img
drwx------ 2 root root  16K Dec  6  2021 lost+found
-rw-r--r-- 1 root root 7.0M Feb 24 15:03 System.map-6.18.7-ipfire
-rw-r--r-- 1 root root 8.9M Feb 24 15:03 vmlinuz-6.18.7-ipfire

The GUI shows “IPFire 2.29 (x86_64) - Core-Update 201” and “An update requires a restart” which obviously I am hesitant to do =)

What should I do?
Reinstall fresh to have the installer create a bigger boot partition and restore the backup from before the update?

dark0ipfire · 6 May 2026 15:20

Exactly the same happened just here, with an Oracle VirtualBox system:

System reboot leads to a running core 201 with no more updates avail.

[root@ipfire ~]# df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        456M  4.0K  456M   1% /dev
tmpfs           485M     0  485M   0% /dev/shm
tmpfs           485M  452K  484M   1% /run
/dev/sda4       7.4G  2.4G  4.6G  35% /
/dev/sda1       110M   76M   26M  75% /boot
/dev/sda2        32M  278K   32M   1% /boot/efi
/var/lock       8.0M   12K  8.0M   1% /var/lock

[root@ipfire ~]# ll /boot/
total 68556
-rw-r--r-- 1 root root   204588 Jan 29 22:38 config-6.18.7-ipfire
drwxr-xr-x 3 root root    16384 Jan  1  1970 efi
drwxr-xr-x 6 root root     4096 May  6 17:09 grub
-rw------- 1 root root 53341640 Jan 30 23:59 initramfs-6.18.7-ipfire.img
drwx------ 2 root root    16384 Jan 18  2022 lost+found
-rw-r--r-- 1 root root  7261974 Jan 29 22:38 System.map-6.18.7-ipfire
-rw-r--r-- 1 root root  9352192 Jan 29 22:38 vmlinuz-6.18.7-ipfire
[root@ipfire ~]#

bbitsch · 6 May 2026 15:32

The date of the initramfs file is the date of CU200. In my system.

bonnietwin · 6 May 2026 15:43

Your boot partition is 110MiB.

The size for new installations was increased to 256MiB in 2022 with CU170.

Then in 2023 with CU175 it was increased to 512MiB as that is the minimum required for an XFS filesystem.

Yes my recommendation would be to do a fresh install and thereby ensure that you have a large enough boot partition not only for now but also for the future as the kernel size just keeps on increasing.

bbitsch · 6 May 2026 15:54

Looking at the current state of dracut skript shows, that even with option --force initramfs isn’t just overwritten but the operation is create tmp file → cp to destination file. This means that the space for initramfs is needed twice.
In CU200 this wasn’t the case. Therefore until now the process succeeded without problems.

dark0ipfire · 7 May 2026 09:27

Indeed, the partition /boot in fresh installation looks much better:

[root@ipfire ~]# df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        445M  4.0K  445M   1% /dev
tmpfs           485M     0  485M   0% /dev/shm
tmpfs           485M  484K  484M   1% /run
/dev/sda4       7.1G  2.1G  4.7G  31% /
/dev/sda1       488M   98M  354M  22% /boot
/dev/sda2        32M  294K   32M   1% /boot/efi
/var/lock       8.0M   12K  8.0M   1% /var/lock
[root@ipfire ~]#
[root@ipfire ~]# ll /boot/
total 90688
-rw-r--r-- 1 root root   204588 Apr 21 15:04 config-6.18.7-ipfire
drwxr-xr-x 3 root root    16384 Jan  1  1970 efi
drwxr-xr-x 6 root root     4096 May  7 10:27 grub
-rw------- 1 root root 76082445 Apr 21 15:06 initramfs-6.18.7-ipfire.img
drwx------ 2 root root    16384 May  7 10:27 lost+found
-rw-r--r-- 1 root root  7261974 Apr 21 15:04 System.map-6.18.7-ipfire
-rw-r--r-- 1 root root  9274368 Apr 21 15:04 vmlinuz-6.18.7-ipfire

Maybe a general warning should be issued on systems with 110M /boot partition size to better do a fresh installation and no more updates.

ramfast · 9 May 2026 18:49

So according to your remark, I should stay with release 200 instead of migrating to 201 ?

BR

bonnietwin · 11 May 2026 09:19

My recommendation would be to take a backup. Download it from the IPFire system. Do a fresh install from a CU201 iso and then do a restore from the backup.

That way you will get a new boot partition that will be 512MiB and you will not run out of space with any updates.

You can also create an ISO backup and buse that for the install and restore in one go.

I have not tested that myself for several years. I always use normal install iso and a separate backup as I have processes on my IPFire system to automatically create backups on a weekly basis and then back them up to a central backup server using bacula.

larsen · 11 May 2026 10:21

I have used this method when the /boot partition needed to be resized the first time some years ago. This went quite well, however, I needed to reinstall all addons manually, so make a list before you do this.

There is a feature request that hasn’t been implemented, yet.

ramfast · 11 May 2026 11:06

Hi,
Yes I agree with you, should be very helpfull

ramfast · 15 May 2026 18:37

Thank’s Lars & Adolf

Done today. I made a backup of IPF release 200
I have restored it. Hopefully I have made of list for the addons.
The size of the boot partition was increased, so seems good for CU 201
In few days I will upgrade to CU 201

Thx