# NomadBSD: DHCP Not Started on Link-Up (devd rule priority conflict)

Follow-up to the FreeBSD 15.1 stock-kernel/fusefs-unionfs patch.
Applies on top of it (or on master): nomadbsd-devd-dhclient.patch
(4 files, +53/-26).

## Symptom

No IPv4 address after link-up on wired or wireless interfaces. IPv6
(SLAAC) works. `service dhclient start <if>` works when run manually;
the rc.conf DHCP marker and the base /etc/devd/dhclient.conf rules are
all present and correct.

## Root cause

devd(8) executes only the *single highest-priority rule* matching an
event. Equal priorities are resolved by config scan order, which
follows readdir() - i.e. filesystem directory-entry order, an accident
of file creation sequence during image build.

Two rule sets outbid the base system's "notify 0" dhclient rules:

1. NomadBSD's own /usr/local/etc/devd/fetch-fw.conf matched
   IFNET (LINK_UP|ADDR_ADD) at notify 100 - the same priority and
   event as NomadBSD's dhclient override rules. Whichever file
   happened to be scanned first won the tie. On older images
   dhclient.conf won; on rebuilt images fetch-fw.conf wins, and the
   result is a deadlock: fetch-fw takes the LINK_UP slot and waits
   for DNS over a network that has no IPv4 because dhclient never ran.
2. NetworkMgr ships "notify 5" IFNET rules. The build sed-commented
   the setup-nic/auto-switch *action* lines, leaving action-less
   rules that still match and win against notify-0 - silently
   swallowing events. A newer action (link-up.py) postdates the sed
   patterns entirely and was never disabled.

The dhclient override itself lived at /usr/local/etc/devd/ - inside
the uzip - making its visibility to devd dependent on rc ordering.

## Fix

- New /etc/devd/nomadbsd-dhclient.conf (root filesystem) with the
  LINK_UP dhclient rules at notify 200 - strictly above everything
  else on the image, no ties possible. The stock
  /etc/devd/dhclient.conf is left untouched (etcupdate/freebsd-update
  would revert local edits to it).
- /usr/local/etc/devd/dhclient.conf removed (superseded).
- fetch-fw.conf now matches ADDR_ADD only - it runs after dhclient
  (or static config) assigns an address, which is what its
  wait-for-DNS logic wants anyway.
- configure_networkmgr() now replaces networkmgr.conf with a
  comment-only file instead of sed-commenting action lines, removing
  the action-less rule shells. (Also fixes a latent sed bug: the
  patterns used "[::space::]", which is not a valid character class.)

## Verification

After rebuild (or after copying the two devd conf changes onto a
running system and `service devd restart`):

1. Unplug/replug ethernet, or reassociate wifi: IPv4 arrives within a
   few seconds on both.
2. `grep fwget /var/log/fetch-fw.log` after a fresh link-up: fetch-fw
   still runs (now post-address).
3. If /etc/devd/dhclient.conf was manually edited during debugging,
   restore it to the stock "notify 0" version - the override file
   makes local modifications to base files unnecessary.