Core Update 200 has been released for Testing.
For those who are able to, please support with evaluation of this new release.
If you have not seen the announcement here is a link to it.
https://www.ipfire.org/blog/ipfire-2-29-core-update-200-is-available-for-testing
I upgraded, via WUI, on a basic, low-end, installation. It went smoothly.
I have upgraded 4 vm systems and 1 physical system with a wireless card built in.
All updates went smoothly.
One of the vm systems is running IPS with a set of 14 rulesets from the Emerging Threats provider.
Before update the suricata sgh cache directory was at 59M. After update and the running of the cache pruning the sgh directory was down at 16M.
Upgraded one test system 199→200 no issues. Tested Libvirt afterwards, VM startup, running and virsh backup also no issues. 
There was no 199 Testing, it went directly to release?
200 was updated without trouble, on my Testing system I mostly run the standard stuff plus a couple of OpenVPN Net-to-Net links however.
Yes there was a CU199 Testing.
https://www.ipfire.org/blog/ipfire-2-29-core-update-199-is-available-for-testing
[Sat Jan 31 08:11:10.877520 2026] [mpm_event:notice] [pid 5986:tid 5986] AH00489: Apache/2.4.65 (Unix) OpenSSL/3.6.0 configured -- resuming normal operations
[Sat Jan 31 08:11:10.877928 2026] [core:notice] [pid 5986:tid 5986] AH00094: Command line: '/usr/sbin/httpd'
[Sat Jan 31 09:24:23.216672 2026] [core:error] [pid 5991:tid 6008] (13)Permission denied: [client 192.168.12.10:50570] AH00035: access to /cgi-bin/pakfire.cgi denied (filesystem path '/srv') because search permissions are missing on a component of the path, referer: https://192.168.12.2:444/
[Sat Jan 31 09:24:24.240102 2026] [core:error] [pid 5991:tid 6018] (13)Permission denied: [client 192.168.12.10:50570] AH00035: access to /cgi-bin/speed.cgi denied (filesystem path '/srv') because search permissions are missing on a component of the path, referer: https://192.168.12.2:444/
[Sat Jan 31 09:25:21.070874 2026] [core:error] [pid 5991:tid 5997] (13)Permission denied: [client 192.168.12.10:50570] AH00035: access to /cgi-bin/speed.cgi denied (filesystem path '/srv') because search permissions are missing on a component of the path, referer: https://192.168.12.2:444/
[Sat Jan 31 09:25:22.073493 2026] [core:error] [pid 5991:tid 6010] (13)Permission denied: [client 192.168.12.10:50570] AH00035: access to /cgi-bin/pakfire.cgi denied (filesystem path '/srv') because search permissions are missing on a component of the path, referer: https://192.168.12.2:444/
[Sat Jan 31 09:25:23.074914 2026] [core:error] [pid 5991:tid 6012] (13)Permission denied: [client 192.168.12.10:50570] AH00035: access to /cgi-bin/speed.cgi denied (filesystem path '/srv') because search permissions are missing on a component of the path, referer: https://192.168.12.2:444/
[Sat Jan 31 09:25:24.062071 2026] [core:error] [pid 5991:tid 6008] (13)Permission denied: [client 192.168.12.10:50570] AH00035: access to /cgi-bin/pakfire.cgi denied (filesystem path '/srv') because search permissions are missing on a component of the path, referer: https://192.168.12.2:444/
[Sat Jan 31 09:25:30.168742 2026] [core:warn] [pid 5986:tid 5986] AH00045: child process 5991 still did not exit, sending a SIGTERM
[Sat Jan 31 09:25:32.170736 2026] [core:warn] [pid 5986:tid 5986] AH00045: child process 5991 still did not exit, sending a SIGTERM
[Sat Jan 31 09:25:34.172731 2026] [core:warn] [pid 5986:tid 5986] AH00045: child process 5991 still did not exit, sending a SIGTERM
[Sat Jan 31 09:25:36.174724 2026] [core:error] [pid 5986:tid 5986] AH00046: child process 5991 still did not exit, sending a SIGKILL
[Sat Jan 31 09:25:36.892349 2026] [mpm_event:notice] [pid 7960:tid 7960] AH00489: Apache/2.4.66 (Unix) OpenSSL/3.6.1 configured -- resuming normal operations
[Sat Jan 31 09:25:36.892581 2026] [core:notice] [pid 7960:tid 7960] AH00094: Command line: '/usr/sbin/httpd'
[Sat Jan 31 09:26:15.756975 2026] [core:error] [pid 7964:tid 7976] (13)Permission denied: [client 192.168.12.10:50617] AH00035: access to /cgi-bin/pakfire.cgi denied (filesystem path '/srv') because search permissions are missing on a component of the path, referer: https://192.168.12.2:444/
[Sat Jan 31 09:26:16.051570 2026] [core:error] [pid 7964:tid 7995] (13)Permission denied: [client 192.168.12.10:50617] AH00035: access to /favicon.ico denied (filesystem path '/srv') because search permissions are missing on a component of the path, referer: https://192.168.12.2:444/
That’s why I’m afraid to update via WUI. 
edit
After refreshing the page.
edit
Clamav logs after installation.
|10:09:23 |clamd[6331]: |Self checking every 600 seconds.|
|10:09:23 |clamd[6331]: |OneNote support enabled.|
|10:09:23 |clamd[6331]: |HWP3 support enabled.|
|10:09:23 |clamd[6331]: |XMLDOCS support enabled.|
|10:09:23 |clamd[6331]: |HTML support enabled.|
|10:09:23 |clamd[6331]: |SWF support enabled.|
|10:09:23 |clamd[6331]: |PDF support enabled.|
|10:09:23 |clamd[6331]: |OLE2 support enabled.|
|10:09:23 |clamd[6331]: |Mail files support enabled.|
|10:09:23 |clamd[6331]: |ELF support enabled.|
|10:09:23 |clamd[6331]: |Portable Executable support enabled.|
|10:09:23 |clamd[6331]: |Heuristic alerts enabled.|
|10:09:23 |clamd[6331]: |AlertExceedsMax heuristic detection disabled.|
|10:09:23 |clamd[6331]: |Detection using image fuzzy hash enabled.|
|10:09:23 |clamd[6331]: |Image (graphics) scanning support enabled.|
|10:09:23 |clamd[6331]: |Archive support enabled.|
|10:09:23 |clamd[6331]: |Limits: PCREMaxFileSize limit set to 104857600.|
|10:09:23 |clamd[6331]: |Limits: PCRERecMatchLimit limit set to 2000.|
|10:09:23 |clamd[6331]: |Limits: PCREMatchLimit limit set to 100000.|
|10:09:23 |clamd[6331]: |Limits: MaxRecHWP3 limit set to 16.|
|10:09:23 |clamd[6331]: |Limits: MaxIconsPE limit set to 100.|
|10:09:23 |clamd[6331]: |Limits: MaxPartitions limit set to 50.|
|10:09:23 |clamd[6331]: |Limits: MaxZipTypeRcg limit set to 1048576 bytes.|
|10:09:23 |clamd[6331]: |Limits: MaxScriptNormalize limit set to 20971520 bytes.|
|10:09:23 |clamd[6331]: |Limits: MaxHTMLNoTags limit set to 8388608 bytes.|
|10:09:23 |clamd[6331]: |Limits: MaxHTMLNormalize limit set to 41943040 bytes.|
|10:09:23 |clamd[6331]: |Limits: MaxEmbeddedPE limit set to 41943040 bytes.|
|10:09:23 |clamd[6331]: |Limits: Files limit set to 10000.|
|10:09:23 |clamd[6331]: |Limits: Recursion level limit set to 17.|
|10:09:23 |clamd[6331]: |Limits: File size limit set to 104857600 bytes.|
|10:09:23 |clamd[6331]: |Limits: Global size limit set to 419430400 bytes.|
|10:09:23 |clamd[6331]: |Limits: Global time limit set to 120000 milliseconds.|
|10:09:23 |clamd[6331]: |LOCAL: Setting connection queue length to 200|
|10:09:23 |clamd[6331]: |LOCAL: Unix socket file /var/run/clamav/clamd|
|10:09:18 |clamd[6331]: |Loaded 340188 signatures.|
|10:09:14 |freshclam[6232]: |--------------------------------------|
|10:09:14 |freshclam[6232]: |Clamd was NOT notified: Can't connect to clamd through /var/run/clamav/clamd: No such file or directory|
|10:09:14 |freshclam[6232]: |bytecode.cvd updated (version: 339, sigs: 80, f-level: 90, builder: nrandolp)|
|10:09:14 |freshclam[6232]: |Database test passed.|
|10:09:14 |freshclam[6232]: |Testing database: '/var/lib/clamav/tmp.4c24e28891/bytecode.cvd' ...|
|10:09:14 |freshclam[6232]: |bytecode database available for download (remote version: 339)|
|10:09:14 |freshclam[6232]: |main.cvd updated (version: 63, sigs: 3287027, f-level: 90, builder: tomjudge)|
|10:09:14 |freshclam[6232]: |Database test passed.|
|10:09:10 |clamd[6331]: |Bytecode: Security mode set to TrustSigned.|
|10:09:10 |clamd[6331]: |Not loading PUA signatures.|
|10:09:10 |clamd[6331]: |Reading databases from /var/lib/clamav|
|10:09:10 |clamd[6331]: |Log file size limited to 1048576 bytes.|
|10:09:10 |clamd[6331]: |clamd daemon 1.5.1 (OS: Linux, ARCH: x86_64, CPU: x86_64)|
|10:09:10 |clamd[6331]: |Received 0 file descriptor(s) from systemd.|
|10:09:07 |freshclam[6232]: |Testing database: '/var/lib/clamav/tmp.4c24e28891/main.cvd' ...|
|10:09:05 |freshclam[6232]: |main database available for download (remote version: 63)|
|10:09:05 |freshclam[6232]: |daily.cvd updated (version: 27898, sigs: 354869, f-level: 90, builder: svc.clamav-publisher)|
|10:09:05 |freshclam[6232]: |Database test passed.|
|10:08:56 |freshclam[6232]: |Testing database: '/var/lib/clamav/tmp.4c24e28891/daily.cvd' ...|
|10:08:55 |freshclam[6232]: |daily database available for download (remote version: 27898)|
|10:08:55 |freshclam[6232]: |ClamAV update process started at Sat Jan 31 10:08:55 2026|
|10:08:55 |freshclam[6232]: |freshclam daemon 1.5.1 (OS: Linux, ARCH: x86_64, CPU: x86_64|
In core 200 (Add-On - Services), the hostapd status is displayed incorrectly.
The Wireless Access Point is working properly.
The clamav logs look fine. So that confirms that the changes to the 1.5.1 clamav build are now working correctly.
All the lines like this are saying that you have incorrect permissions on one or mora parts of the paths under /srv/
The path permissions are not changed in anything the updates do.
Have you edited or copied files somewhere into the /srv/ directory tree?
These incorrect permissions will stay there so you will end up with the same problem in the future if it is not fixed.
The simplest way to fix it is to do a backup and save it off of the IPFire system, then do a fresh install and then restore the backup.
You could try and find which directories have the wrong permissions but you would have to figure out what were the correct permissions for each directory in the /srv/ tree to be sure everything is correct.
This is what my system has both on the Services and the WAP pages
So on my system it is showing running on both pages.
What happens if you press the restart symbol on the Services page?
If you refresh the WAP page does the status still show Running?
Upgraded without any hassle.
Tested Services: IPsec Host-To-Host, WireGuard Host-To-Net, OpenVPN Host-To-Net without OTP, IPS with ET and IPFire DBL, URL-Filter with IPFire DBL, LLDP, Samba, Wireless AP, ExtraHD, MiniDLNA, tshark, Tor, qemu, Transmission, ClamAV
Systemlog shows no uncommon entries.
Add-On - Services - shows the status as stopped, only start can be selected - no status change when pressed.
Wireless Access Point - status as running, start or stop can be selected - working properly.
Wireless Access Point - working properly, supports WLAN clients.
IPFire 2.29 (aarch64) - Core-Update 200 Development Build: master/e3cf89f1
I got this status after pressing the red down stop arrow.
So this is what you are presumably seeing on your Services page but with this I then see the following on my WAP page.
and the System logs have the following lines.
12:36:58 hostapd: blue0: interface state ENABLED->DISABLED
12:36:58 hostapd: blue0: AP-DISABLED
12:36:58 hostapd: blue0: CTRL-EVENT-TERMINATING
12:36:58 hostapd: nl80211: deinit ifname=blue0 disabled_11b_rates=0
So the blue interface was disabled.
Then I press the Green up start arrow and the services page changes to
and the WAP page shows running status and the system logs show
12:38:22 hostapd: blue0: interface state UNINITIALIZED->COUNTRY_UPDATE
12:38:22 hostapd: blue0: interface state COUNTRY_UPDATE->ENABLED
12:38:22 hostapd: blue0: AP-ENABLED
The services.cgi page was not changed in CU199 or in CU200.
Some fixes were put into CU200 to remove any DEBUG line in the settings file and also to allow the use of ! in the PSK password but those should just replace the hostapd initscript file in your system.
As long as the initscript is named hostapd and the status section in that initscript is correct then the services.cgi page just gets the status feedback and uses that to update the services page.
I can’t reproduce the effect that you are having.
If the hostapd wap is accepting wireless clients successfully then it looks like the hostapd daemon is running.
Can you run the command
/etc/rc.d/init.d/hostapd status
you should see the following result but with a different Process ID
hostapd is running with Process ID(s) 20420.
if the status command is working correctly.
I would expect this to be the case as the WAP is working for clients and it shows the status Running at the top of the WAP page.
In that case the only thing I can think of is that the services.cgi page is not asking for the status correctly but then its code must have been modified in some way on your system.
Are all addons on your system showing as stopped or just the hostapd or do you not have any others?
If the latter then I would suggest installing the guardian addon and enabling it and then see if it shows up as running on the Guardian WUI page and the Services page or just on the Guardian WUI page.
Correct, It only shows badly.
Shows correctly, as intended.
I have a different platform - Arm hardware.
For the services.cgi code that should not make any difference. Also the initscript should be the same as fa as I can tell. Only the actual hostapd binary would be different.
Okay, so all addons except hostapd show correctly on the Services page so the services.cgi status code is working correctly so the problem is not there.
What result did you get on your system with this command?
If you run the command
less /opt/pakfire/db/installed/meta-hostapd
do you get the following output
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Name: hostapd
Summary: Daemon for running a WPA capable Access Point
ProgVersion: f747ae0
Release: 72
Size: 634880
Dependencies:
File: hostapd-f747ae0-72.ipfire
Services: hostapd
especially the last line?
[root@ipfire ~]# /etc/rc.d/init.d/hostapd status
Invalid value ‘[MAX-MPDU-3895][SHORT-GI-80][SU-BEAMFORMEE]’ for key ‘VHTCAPS’
Invalid value ‘[MAX-AMSDU-3839][HT40+][SHORT-GI-20][SHORT-GI-40][DSSS_CCK-40]’ for key ‘HTCAPS’
hostapd is running with Process ID(s) 3563.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Name: hostapd
Summary: Daemon for running a WPA capable Access Point
ProgVersion: f747ae0
Release: 72
Size: 573440
Dependencies:
File: hostapd-f747ae0-72.ipfire
Services: hostapd
This is likely the problem. The code in the services.cgi page will look for some text from the Process ID line but maybe assumes the status output is just a single line.
The invalid values should not be occurring but I am not familiar enough with wireless capabilities to know how to check through the initscript code to see if this is a problem with the wireless card providing incorrect capabilities or if there is some bug in the initscript extraction of capabilities.
@ms or one of the other devs would be better placed to investigate that.
Also was the hostapd service showing as not running on the services page also with CU199?
I am not aware of any change in the capability extraction part of the initscript from CU199 to CU200.