Following the release of Core Update 183, I updated two devices. In both cases,
the web server on the device stopped and the prompt on the console screen was not responsive.
After a few minutes, the prompt on console screen refreshed and I was able to login (still no web interface)
I logged in as root and issued the command reboot -n
All’s good following the reboot.
I updated 4 devices. All 4 had the web server continue operating and was able to do the reboot from the WUI without any hiccups.
What do the core update logs indicate occurred?
The log looks like the upgrade was uneventful.
I received errors on upgrade ,and All “Status” section except (mdstat,inet traffic, connections) n web interface are not working.
"Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator at root@localhost to inform them of the time this error occurred, and the actions you performed just before this error.
More information about this error may be available in the server error log."
[root@morgul httpd]# tail -f error_log
Compilation failed in require at /var/ipfire/graphs.pl line 26.
BEGIN failed–compilation aborted at /var/ipfire/graphs.pl line 26.
Compilation failed in require at /srv/web/ipfire/cgi-bin/memory.cgi line 31.
[Wed Feb 14 01:12:58.056150 2024] [cgid:error] [pid 4811:tid 129750676788928] [client 192.168.0.30:45754] End of script output before headers: memory.cgi, referer: https://192.168.0.1:444/
Can’t load ‘/usr/lib/perl5/site_perl/5.36.0/x86_64-linux-thread-multi/auto/RRDs/RRDs.so’ for module RRDs: libxml2.so.2: cannot open shared object file: No such file or directory at /usr/lib/perl5/5.36.0/x86_64-linux-thread-multi/DynaLoader.pm line 206.
at /var/ipfire/graphs.pl line 26.
Compilation failed in require at /var/ipfire/graphs.pl line 26.
BEGIN failed–compilation aborted at /var/ipfire/graphs.pl line 26.
Compilation failed in require at /srv/web/ipfire/cgi-bin/memory.cgi line 31.
[Wed Feb 14 01:12:59.588912 2024] [cgid:error] [pid 4811:tid 129750785828544] [client 192.168.0.30:47816] End of script output before headers: memory.cgi, referer: https://192.168.0.1:444/
These errors appear to affect only Status page in the GUI.
Have you rebooted since the upgrade ?. If not, then save your backup, in preparation for reinstall, if required, then reboot.
I’ve upgraded two fairly different hardware from cu182 to cu183 and the GUI Status page is working OK.
I have rebooted. The problem is missing libxml2.so.2 in /usr/lib64/. Other web pages doesn’t work too.
Unless someone who is experienced with the development of IPFire can help, then your best option would be to make a backup and do a fresh install
core183 ships /usr/lib/libxml2.so.2 and usr/lib/libxml2.so.2.12.3 so this file should not missing.
( /usr/lib64 should a symlink to /usr/lib )
i assume there was an error at unpack the archive or a write error to your disk. (is there enough space free ?)
There are missing, but i try to restore with backup from core 181 and reatore all configurations. After new try to upgrade, there is no problem. Yesterday’s night upgrade process return some errors from some download servers. Maybe not all files are downloaded correctly.
Just did the update and noticed this Note at the bottom of the the WUI Home page …
Filesystem full: efivarfs Free=0% !
At the console df -h shows …
Filesystem Size Used Avail Use% Mounted on
devtmpfs 3.9G 4.0K 3.9G 1% /dev
tmpfs 3.9G 0 3.9G 0% /dev/shm
tmpfs 3.9G 832K 3.9G 1% /run
/dev/sda4 57G 2.7G 52G 5% /
efivarfs 128K 123K 153 100% /sys/firmware/efi/efivars
/dev/sda1 488M 58M 394M 13% /boot
/dev/sda2 32M 278K 32M 1% /boot/efi
/var/lock 8.0M 16K 8.0M 1% /var/lock
Is this something of concern?
efivars should be not a problem.
Updated 25 firewalls with diverse hardware from 181/182 to 183 last night. No issues.
I had on 2 instances issues so far. One was a proxmox virtual ipfire and another one running on intel hardware industrial grade PC. On both the WebUI stopped working and I had to issue a reboot after that they seem to work normally.
I also had such an issue when going to 182 on one of the firewalls and the annoying thing is it is a remote one. The Firewall and Internet capabilities are still working but no access to WebUI is possible and it is holiday time so no one on site so I have to drive there and issue a reboot manually 
I really had this “WebUI gone bad” issue now on multiple updates in the last year. Such things of course makes you hesitating and not want to update if it triggers such issues.
Would it not be possible to just restart the WebUI after an update as a preventive measure?
I really now have to remind myself all the time to turn on SSH access in case the WebUI is not coming back. That way I can at least reboot it. But I really think this should not be necessary
All desktop, mostly old dell optiplex.
Now I just have to do the other 30…
I have updated to core183 and freeradius is not starting anymore. No entries in /var/log/radius/radius.log, it just fails.
In debug mode, is see this:
# /usr/sbin/radiusd -X -d /etc/raddb
libssl version mismatch. built: 30100020 linked: 30200010
Argh… This possible has an impact on even more functions in IPfire.
All of my wifi APs are out of order now…
I have filed a bug: 13590 – Freeradius not starting: libssl version mitsmatch
Very similar problem on update to 183 from 182.
Running on a Hyper-V VM, command prompt stuck on reloading.
Waited 10 minutes and the console accepted an input but no web interface. Logged in as root, ran the reboot -n command and all is well after reboot.
This indicates that radius is linked to openssl and therefore radius needs to be incremented and shipped every time there is an openssl update.
The problem has obviously been there since Core Update 180 because Openssl was updated to 3.1.4 in Core Update 181 and then to 3.2.1 in Core Update 183.
Unfortunately no one using the radius addon tested out the Core Updates 181, 182 or 183.
I will run a build to increment radius so it gets shipped with Core Update 184.
In the meantime the only option I think is to run a backup, save it and then do a fresh install of Core Update 180 and restore.
Thanks! I choose to wait for core184 and change all of my access points to be using WPA2/WPA3-PSK instead of 802.1X temporarily…
And Intel CPU?