After update ipfire to 157, no boot

These are just files being extracted…


Till now I dont see something about missing , some kernel things but looks ok no error or missing.

But maybe I am looking on the wrong and to fast… :see_no_evil:

In the grub folder on the HDD, i see files in i386pc and x86_64efi

So i can’t onderstand what it didn’t see

The Firewall is back in action, but web proxy don’t work , the add-on are installed and back-up is restored and did a reboot.

For now my wife is happy because we have safe internet, tomorrow I will keep going and check what is going wrong.

Thanks again @ms Michael!!

1 Like

Same problem with my apu. Update went fine, reboot → grub, missing kernel. Had to restore an older backup v 148. After the update process v157 did boot without issues.

Hi Everyone, today i start trying some small things with the webproxy, and I noticed it works with squidclam on, as soon I turn url filter it stopt.

I just dont know if it’s from v157 or 156 as i already have problem with after rebooting no webproxy:

Same issue here - It did not boot after upgrade from v156 to v157 and stopped in Grub.
Hardware: IPFire Mini Appliance
Reinstalling from USB Stick was not as straight forward as before. Has taken several hours of try and error. Eventually I brought it up & was able to restore a recent configuration backup.

Same here. Same problem on an APU1 machine from a friend. He has a second hard drive as a backup so for now I did not yet fix the problem with a fresh reinstall but I will need to do it soon. I am holding up the update for my APU2 router for now.

Hi all,

since I got a bit lost here: Is anybody experiencing this problem on a different hardware than the IPFire Mini Appliance or the APU family? While upgrading to Core Update 157, I did not experience trouble on my firewalls, so we at least did not seem to break every system out there. :wink:

Also, could you please share the contents of /var/log/pakfire (as @ms asked already) and the output of df -h here?

Thanks, and best regards,
Peter Müller

1 Like

Hey @pmueller, my hardware is not Ipfire mini,

I don’t if you mean my log file ore other person’s but mine log file is in the reply of @ms in a zip file as i was not aloud to add txt file.

I didn’t see anything good and if i saw something strange for me was it normal for the developers…

I hope I could be more helpful, let me know what I could do, I already clean install but maybe there’s still something.

I will, next week end when I fix my friend’s machine.

@pmueller reading to fast after work😅, it’s a Apu family but not a Ipfire mini.

Sorry for the fast reading and reply.

Best regards.

Ok, related question, I have two work IPFire boxes, one is local, one is remote, and both are currently running 156 but I processed the 157 update on both of them, they have to restart for the upgrade to to take effect, is there a way that I can cancel the pending install of 157? I do NOT want to restart and try to boot 157 after hearing the challenges that multiple people are having.

@neopegasus, @angrytux, @thier28, @cfusco -

Folks - you’ve been asked to supply some information to help the IPFire Developers figure out this issue.

There are two easy commands:

cat /var/log/pakfire

df -h

Please help us help you!

Zip files are fine.


You will have to reinstall IPFire and then restore your backup.

Carrying out the upgrade will have installed all the new files. Some won’t be properly active till after a reboot.

Fir info, my production IPFire system upgraded from 156 to 157 without a murmur.
All my services that were running before were running after update and reboot.

I have also done several vm updates from 156 to 157 and again no hiccups.

Some people are having issues but I suspect the majority not.

Currently 27.03% of users are on Core Update 156
Already there are 23.83% of users on Core Update 157



to share my current guess (!) publicly: We have increased the size of the /boot partition several times during the last ~ 5 years, as the Linux kernel grew bigger and bigger. Unfortunately, this requires reinstalling IPFire, since mounted partitions cannot be changed by the same operating system that is running out of them.

I could imagine the affected people to run some IPFire installations that have been active for a very long time (> 4 years), hence still having a relatively small /boot partition. However, as far as I am aware, we do not install a kernel if we can foresee running out of disk space - an upgrade should simply stop before touching anything on disk.

So, there might be a bug in this routine, causing disk space miscalculations. However, that would not really explain why Grub is affected, but is the only idea I have at hand given the patchy facts. :slight_smile:

This is why I am asking for df -h information. Let’s see if the affected systems share a small /boot partition in common.

Thanks, and best regards,
Peter Müller


Peter hi , this is my df -h :

[root@PegasusFirewall ~]# df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        3.9G  4.0K  3.9G   1% /dev
tmpfs           3.9G   12K  3.9G   1% /dev/shm
tmpfs           3.9G  616K  3.9G   1% /run
/dev/sda4       457G  3.7G  430G   1% /
/dev/sda1       110M   35M   67M  34% /boot
/dev/sda2        32M  254K   32M   1% /boot/efi
/var/lock       8.0M   12K  8.0M   1% /var/lock
none            3.9G  468K  3.9G   1% /var/log/vnstat
none            3.9G   53M  3.8G   2% /var/log/rrd

This is the reinstall ipfire 157 , I hope I understand you right.

and i hope it helps.

ps i just did a upgrade last weekend ( so after the problem with 157) the old system has 350g hdd the new have 500ssd

1 Like

Here is ours - it is unknown if we are affected here or not yet.

[root@ipfire pakfire]# df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        3.9G  4.0K  3.9G   1% /dev
tmpfs           3.9G   12K  3.9G   1% /dev/shm
tmpfs           3.9G  668K  3.9G   1% /run
/dev/sda4       116G   85G   26G  77% /
/dev/sda1       110M   35M   67M  34% /boot
/dev/sda2        32M  254K   32M   1% /boot/efi
/var/lock       8.0M   12K  8.0M   1% /var/lock
1 Like

Hey Jon, my log/zip file is here BTW ;

1 Like

Hi All,
It happened to me too. I have a relatively new firewall appliance that has a intel J3160 processor. Purchased the device back in January of this year so it has not been running long. At the initial install I would have put the latest version on the device, so it would have been a Jan 2021 version (not sure what release). To recover, I had to do a new install with backup recovery to get it up and running again. The profile is 052661e7f9c06c03afdb1fb849ac27cbbf7f860e, assuming it does not change from a complete rebuild. ( Which is a question, does the profile id change after a complete rebuild of the system?, just curious. ) On the other hand, my backup firewall device, which has a i3-4005U processor, updated just fine (it started at release 154), its profile id is 3dce541a03a2724dab08ca9ccfd03875fc3dc899.

I am not sure thattelling you the disk allocation after recovery will tell you anything as I have no way to determine if things changed from the pre-core 157 upgrade.

I hope this helps, P