On 2025-09-12 00:04, Anubhav/FreeBSD wrote:
On Thu, Sep 11, 2025 at 8:29 PM Anubhav/FreeBSD wrote:I did not find anything about changes related to pf(4) in src/UPDATING for v14.3, also found nothing relevant via web search or in -stable@ list from 202505 to now. After direct OS update from v13.5-RELEASE-p2 to v14.3-REELASE-p2 viafreebsd-update(8), I got a message during booting into v14.3 (from "dmesg -a";same is also in /var/log/console.log): ... [105.659700] add net ::ffff:0.0.0.0: gateway ::1 [105.660183] add net ::0.0.0.0: gateway ::1 [105.666161] Enabling pfrules cleared [105.671398] nat cleared [105.671407] 0 tables deleted. [105.672823] 0 states cleared [105.674735] source tracking entries cleared [105.674816] pf: statistics cleared [105.674819] pf: interface flags reset [105.679224] pfctl: DIOCADDRULENV: File exists [105.680156] /etc/rc: WARNING: Unable to load /etc/pf.conf.custom ... /etc/rc.conf has: pf_enable="YES" # Flush all pf_flags="-F all" pf_fallback_rules='pass all' pf_rules='/etc/pf.conf.custom' # pflog_logfile="/var/log/pf.log" pflog_enable="YES" After I saw that message, verified via "pfctl -v -v -s rules" that indeed no rules had been loaded. A dry run, "pfctl -n -v -v -f /etc/pf.conf.custom", did not produce any issue that could be due to the rules; without "-n" option, rules were loaded without issues. Same thing had happened on another machine with same enough hardware (CPU, motherboard, (at least amount of) RAM, & use of SSD to boot OS) with same 14.3-RELEASE-p2.I rebooted the "another machine" -- call it "2nd machine" -- to check if the issue would happen again on warm reboot. It did not. Does that mean some kernel state persisted enough during booting into v14.3 from v13.5 that loading of pf rules had failed? Also, I have been using stable/14 on a 3rd machine where I had not seen the issue post-reboot which had been (re)booted multiple times (since it got stable/14). That gave me enough confidence/courage to try to reboot the above 2nd machine to test.
FWIW I seem to recall a similar message. The cause of which was a bad (malformed)
entry in one of our tables. HTH --Chris
- AnubhavWhat am I missing here? Race condition?
-- There is no such place as the internet
0xE512722F.asc
Description: application/pgp-keys