"Filesystem full: /dev/mmcblk0p1 Free=6% !" on Core Update 167 is available for testing


I have chosen to try the CU167 test version and I have this notice:


Why can it be due?



Hello again.

From the unknown. If it appears to me that I have the following Kernel:

[root@bs ~]# uname -mrs
Linux 5.15.23-ipfire aarch64
[root@bs ~]#

And the following Kernels appear in /boot:

[root@bs ~]# find /boot/vmli*
[root@bs ~]#

Can I delete everything about “vmlinuz-5.15.32” that doesn’t seem to be used?

In Ubuntu, there are the following commands:

apt clean
apt auto clean
apt autoremove

Which, as you well know, serve to eliminate / clean the system of unnecessary elements. Is there something like that with the Pakfire?



If i understand properly, you installed cu167 ( 5.15.32) but you are using kernel 5.15.23 which is from cu166. ???

Is this the case, or is uname date prior to update cu167 ?

Maybe wipe drive, reinstall cu167 & restore back-up.

Hi @loup001 for your answer.

I don’t think reinstalling is the solution. For home, it may work, but for someone who is looking for life and has several machines in Clients, it is not a solution. Especially with the problems that there are or were with the Backups.

It has to be fixed with a fix in version 167. I think.

I have tried downloading to the CU166 and reapplying the update (in case it had been updated wrong) and now this appears:



I just had a look through the bugzilla entries since Core Update 167 was released for testing. This hasn’t been raised as a bug by anyone else so I would raise it as a bug.


Your IPFire People email and password act as your login credentials for IPFire Bugzilla.


Thanks @bonnietwin.

I have already created:




I understand your position, but respectfully …

is not ideal in your case then … unless you were try to fix something…
append to me too many times … make it worse trying to fix it…


this issue has been fixed by this commit. The current version of Core Update 167 (testing) contains the fix.

Thanks, and best regards,
Peter Müller


I’m on Core update 167 and I have the issue. What can I do to resolve this issue?

Can you add another disk (Services > ExtraHD) ?

It’s the /boot directory. It has something to do with the last update and not cleaning up. pmueller say it fixed in core update 167. I’m on core update 167 and I have the issue.

But which version of CU167. It is in testing so there have been several updates released over the last week. If you updated before 12th April then you would not have the commit that fixes the issue.

1 Like

I’ve been wondering about the newer commits on testing… How do I move to the latest commits?

See the section labelled Update Testing in following wiki link

Looking at the commit, it seems to me to be related to arm devices and your installation is x86_64

Have you checked if you have multiple kernels left in your boot directory.

1 Like

I have the same situation, but have not tried resolving it.

The kernel 5.15.32 files are not being used by the rebooted system. You could try deleting those, after which you might have sufficient free space in /boot to redo the upgrade, to the current testing release, as described earlier.

1 Like



Adolf Belka solution worked.

Good that it worked on your x86_64, but it is now failing worse on arm32, with the boot failing to complete. Other arm32 users should aviod the upgrade until further fixes are made.

1 Like

Hi @rodneyp,

as I just replied to you in the other thread, this issue should have been fixed a while ago now.

Do you experience other boot trouble on 32-bit ARM devices? If so, please tell us about them - to the best of my knowledge, Core Update 167 is finally ready to be released (ETA: next week), but we of course do not want to ship a known faulty update. :slight_smile:

Thanks, and best regards,
Peter Müller

1 Like

As I replied in, boot failure, the issue with /boot filling up was resolved, but the result was worse, with the boot hanging. This is now the subject of bug report bug 12851.

Fresh installing core 166 on arm7hl then upgrading it to core 167 testing is a time-consuming process, which I have not done on all of the many testing builds. If anyone has done so with the latest build 0000-1bd22b04, then they should be able to provide a further report.