@jimp Just ran into this myself with a watchdog report.

I took the following steps:

console option 16 console option 11 rm /var/db/notices_lastmsg.txt

This did not stop the emails. I had to reboot to get it to stop.

I did receive a PHP error report:

[08-Feb-2023 10:00:04 PST8PDT] PHP Fatal error: Uncaught TypeError: fwrite(): Argument #1 ($stream) must be of type resource, bool given in /etc/inc/config.lib.inc:172 Stack trace: #0 /etc/inc/config.lib.inc(172): fwrite(false, 'a:47:{s:7:"vers...') #1 /etc/inc/config.lib.inc(147): generate_config_cache(Array) #2 /etc/inc/config.inc(141): parse_config() #3 /etc/inc/gwlb.inc(25): require_once('/etc/inc/config...') #4 /etc/inc/functions.inc(35): require_once('/etc/inc/gwlb.i...') #5 /etc/inc/notices.inc(26): require_once('/etc/inc/functi...') #6 /usr/local/pkg/nut/nut_email.php(24): require_once('/etc/inc/notice...') #7 {main} thrown in /etc/inc/config.lib.inc on line 172 [08-Feb-2023 10:00:04 PST8PDT] PHP Fatal error: Uncaught ValueError: Path cannot be empty in /etc/inc/notices.inc:101 Stack trace: #0 /etc/inc/notices.inc(101): fopen('', 'w') #1 /etc/inc/config.lib.inc(1162): file_notice('phperror', 'PHP ERROR: Type...', 'PHP errors') #2 [internal function]: pfSense_clear_globals() #3 {main} thrown in /etc/inc/notices.inc on line 101

@jimp said in Latest 23.01 RC updated today - slow WAN on PPOE:

What exactly was the previous build number/date? And which is the current one you upgraded to?

And on what hardware?

seems to be fixed with another update that came today - 23.01.r.20230208.1414

@stephenw10 I only did this because of the memory problem I had before. Interestingly it only happens, if the second Sys Info is reduced. If both have all there boxes checked, there is no problem.

I committed that change to the package so when we do another build, it will be fixed there.

Thanks for testing!

Looks like an improperly translated string, it is missing a character from one of the sprintf format specifiers.

I opened a Redmine issue to get it corrected:

https://redmine.pfsense.org/issues/13946

From what I see, it respects the logging level set to "0" in advanced config.
If I select query level log there it will log... But it will also send huge amount of data to my siem which I dont want it to... I just want to log queries and no more... It seems like its not respecting custom options at boot time...

@jimp I upgraded pfSense to 23.01.r.20230207.0600 and enabled the integration in Home Assistant and it completely works, no errors at all anymore. Thanks a lot for looking into this and fixing it! I guess we can close this issue now :).

I had the exact same issue with an SG-2100. Upgrade appeared to be installing but device never came back up. Connecting console cable to it and checking with Putty looked like it wasn't booting at all. Just had repeating messages about BOOTP broadcasting. Had to re-image. Recommend this RC in lab only for sure.

I had the same problem, with an earlier 2.7 devel version,
after setting it up in console with (pfSense-upgrade) and
rebooting I am now also on 23.01 and with another reboot
all problems are gone too, here.

@bmeeks said in 23.01RC - Suricata stops working after Wireguard installed:

I will look into the Pass List display issue, but it is not the underlying culprit here.

Agree, it's not what's causing the problem, but it's weird behaviour for sure. When setting up my test environment I noticed some other strange things of similar nature. Settings being copied from an interface which was not installed in the new config. I'll do some testing and report back if I find anything...

And great that you have a fix already, but it makes perfect sense to hold off on implementing it.

Thank you - I submitted a fix for it:
https://redmine.pfsense.org/issues/13942

The fix below works on my 2 firewalls. I will test the second fix (kern.ipc.mb_use_ext_pgs=0) tonight on both my firewalls and report back.

===

And then you can use the System Patches package package to disable sendfile:

diff --git a/src/etc/inc/system.inc b/src/etc/inc/system.inc index d36efc2fca..b7cda99366 100644 --- a/src/etc/inc/system.inc +++ b/src/etc/inc/system.inc @@ -1380,7 +1380,7 @@ http { add_header X-Frame-Options SAMEORIGIN; server_tokens off; - sendfile on; + sendfile off; access_log syslog:server=unix:/var/run/log,facility=local5 combined;

After applying that patch, use the console menu option to restart the GUI (11).

@jimp Thanks for the info. This is quite relevant to me as I have a 4860 on hand that I was planning to test with and ultimately plan to update additional 4860 units. From what you've said, I will assume that there is no maybe about it with the 4860 (no other known factors that would avoid the interrupt loop) and that the workaround will be required. While the status LEDs are not critical, it would be nice for them to continue functioning since we do get into situations where they are helpful, so I would be eager to see a fix.

@bob-dig
Same here with 2.6 CE: not able to reach unbounds ULA...working with GUA (which is dynamic, so....not a real solution).
:(

@steveits Thank you, reloading much faster now.

Nice. Yeah pfSense-upgrade does a bunch of things that need to happen.
The fact you both ended up with similar symptoms suggests to me something similar happened. The cause for the upgrade failing may have been different though I agree.