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 via
freebsd-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


- Anubhav


What am I missing here? Race condition?

--
There is no such place as the internet

Attachment: 0xE512722F.asc
Description: application/pgp-keys

Reply via email to