These are just files being extracted…
2 Likes
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… 
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:
https://community.ipfire.org/t/after-reboot-some-time-proxy-server-not-starting/5426/8
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. 
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,
It’s; https://fireinfo.ipfire.org/profile/1e3cc7a973143bb7f3b4a5b82914723a9a452acd
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!
EDIT:
Zip files are fine.
3 Likes
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.
Edit:
Currently 27.03% of users are on Core Update 156
Already there are 23.83% of users on Core Update 157
2 Likes
Hi,
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. 
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
3 Likes
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 ;
https://community.ipfire.org/t/after-update-ipfire-to-157-no-boot/5641/10?u=neopegasus
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