Also, some additional comments concerning things not quite right with settings and/or file permissions;  and different behavior depending on 'update' vs fresh install of CU 164 -- in later comments in this forum post
https://community.ipfire.org/t/manual-update-missing-on-core-164-test/7329/7

(In reply to Charles Brown from comment #1)
> Also, some additional comments concerning things not quite right with
> settings and/or file permissions;  and different behavior depending on
> 'update' vs fresh install of CU 164 -- in later comments in this forum post
> https://community.ipfire.org/t/manual-update-missing-on-core-164-test/7329/7

That has already been raised as its own bug #12788

I can confirm this behavior on Core 164 on multiple systems. The only resolution is to reboot the firewall, but even this does not work consistently. Sometimes after waiting an hour or two, it will return to the normal IPS screen. If more information would be helpful, I will try to record the pattern under which this occurs.

(In reply to Fred Kienker from comment #3)
> I can confirm this behavior on Core 164 on multiple systems. The only
> resolution is to reboot the firewall, but even this does not work
> consistently. Sometimes after waiting an hour or two, it will return to the
> normal IPS screen. If more information would be helpful, I will try to
> record the pattern under which this occurs.

Message displayed on the screen:  	

Ruleset update in progress. Please wait until all operations have completed successfully..

This is from the httpd/error_log:

[Wed Mar 02 13:22:51.398738 2022] [core:error] [pid 2870:tid 136107555538496] (70007)The timeout specified has expired: [client 10.0.2.11:63504] AH00574: ap_content_length_filter: apr_bucket_read() failed, referer: https://fw-at4b.at4b.net:444/

Hello thanks for reporting this issue.

The error occurs because the IDS updater in the background had an error and
did not release it's page lock file correctly.

At the moment to get things work again properly you only can perform a reboot of the system to get rid of this lock or you manually have to remove the "/tmp/ids_page_locked" file by hand.

I'll sent a fix to prevent from having this issue.

-Stefan

Fix has arrived the mailing list:

https://patchwork.ipfire.org/project/ipfire/patch/20220303044943.3678-1-stefan.schantl@ipfire.org/

https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=a956712e75643a4581da8246cef4135a31660746

Per my testing with /master/2022-03-07 18:53:09 +0000-b69659af, this issue is fixed

https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=85b1d83b2a6fe2beb8169f3e810e915c4ad54036

I ran into the same issue.

As I see it the updater 'update-ids-ruleset' wasn't shipped with Core164:

https://git.ipfire.org/?p=ipfire-2.x.git;a=tree;f=config/rootfiles/core/164/filelists;h=c81a06294cd3527b9b68d1352d487bf1c8f95c9e;hb=refs/heads/core164

Ah, zut alors, I was too eager on this one then. :-/

Resetting it back to ON_QA, since https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=ebe404ef020fc5091f5b9cee6e2617fc2e45d279 fixes this problem in Core Update 165, and C165 is already available for testing.

https://blog.ipfire.org/post/ipfire-2-27-core-update-165-is-available-for-testing

https://blog.ipfire.org/post/ipfire-2-27-core-update-165-released