How does /dev/pf get created?

[Gavin Spomer]

I followed your instructions to a "T" and then after I rebooted, I double checked everything to make sure I didn't do
   anything stupid. Still no /dev/pf. Running kldstat still shows that pf.ko didn't get loaded. Trying to load it via your
   instructions (kldload -v pf) I get:

      kldload: can't load pf: No such file or directory

   When I ran this before following your instructions I got something like: (I'm doing this partially from memory)

      kldload: can't load pf.ko: File exists

   That doesn't make a lick of sense to me.

   Stupid (?) question: Is there a way to manually create /dev/pf or can it be copied from another system?

   Thanks for taking the time to help this quasi-newbie. :)

   - Gavin

>>> Jeremy Chadwick <koitsu at FreeBSD.org> 01/25/08 9:08 AM >>>
1) Remove the following lines from your kernel configuration:

device pf
device pflog
device pfsync
options ALTQ

And replace them with just these:

# pf altq support
options         ALTQ
options         ALTQ_CBQ        # Class Bases Queueing
options         ALTQ_RED        # Random Early Drop
options         ALTQ_RIO        # RED In/Out
options         ALTQ_HFSC       # Hierarchical Packet Scheduler
options         ALTQ_CDNR       # Traffic conditioner
options         ALTQ_PRIQ       # Priority Queueing
options         ALTQ_NOPCC      # Required for SMP build
options         ALTQ_DEBUG

2) Remove pf-related lines from /etc/rc.conf and use these instead:

pf_enable="yes"
pflog_enable="yes"

3) Rebuild your kernel and reboot; remove the KERNCONF=xxx stuff if you
went ahead and added the KERNCONF=xxx line to /etc/make.conf.

cd /usr/src
make buildkernel KERNCONF=whatever
make installkernel KERNCONF=whatever
reboot

4) See if pf loads after that.

I'm left thinking there's some bizarre situation where since you have
the "device pf" (and related stuff) in your kernel config hard-coded,
the rc.d/pf script isn't properly initialising pf.

I can assure you that the above steps described are *exactly* what we
use on our RELENG_6 production systems with pf, and we've never run into
any trouble.