Re: Network interface renaming

> On Oct 5, 2025, at 23:40, Lexi Winter <ivy@FreeBSD.org> wrote:
> 
> Chris Ross wrote in <1CB5332A-5E7E-420A-A6AC-3F2D70A0B6C3@distal.com>:
>> 1. Is interface renaming just too dangerous to use?
> 
> i use interface renaming on many systems and have not run into problems
> with it.  however, i don't use local_unbound, and also don't tend to
> rename external or vlan interfaces.

Yeah, I think it’s the vlan interfaces that are the issue.  You mention that
interface renaming happens very early (before the interface is brought
up), but this is clearly not the case for me.  I can see the interfaces being
renamed after the dhclient starts on the primary outside interface.
So probably still somewhere in netif, but interestingly I see after
the renames a “Starting Network: lo0 ix0”.  Note, not including any
of my vlan interfaces.

And, it looks like my local_unbound problem is not related to interfaces.
I took a video of the boot process, and saw the errors there.

> in /etc/syslog.conf, there is a commented example of using syslogd to
> write boot messages to /var/log/console.log.  i suggest enabling this,
> which will make it easier to see where things are failing.


Ahh, that’s helpful, thank you.  I’ve turned that on.  It’s not quite as
good as watching the console, for example the output of interface
renaming is much more in the kernel messages than the single word
output to console, but.  It gives me most things and I’ll enjoy keeping
that.


> On Oct 6, 2025, at 05:46, Dag-Erling Smørgrav <des@FreeBSD.org> wrote:
> 
> Chris Ross <cross+freebsd@distal.com> writes:
>> 1. Is interface renaming just too dangerous to use?
> 
> Yes.  For instance, `service netif stop` and `service netif restart` may
> not work properly, packet filter rulesets may fail to load, etc.

:-)  Clearly multiple opinions on this, thank you for yours.  I worry about
the same.

> Anything that failed to start will presumably have left error messages
> in /var/log/messages.

Sadly not.  There was no information about the local_unbound failure
in any logs, until adding the console.log discussed above.  messages
has a few lines upon _sucessful_ startup, and daemon.log does as
well.

But, I have it now.  It’s an IPv6 error:

Oct  6 11:55:35 logrus kernel: [1759766134] local-unbound[78949:0] error: can't bind socket: Can't assign requested address for 2600:4040:2cc8:f600::1 port 53
Oct  6 11:55:35 logrus kernel: [1759766134] local-unbound[78949:0] fatal error: could not open ports

I’m not sure how to prevent this, since these addresses were just
assigned moments earlier by dhcpcd, and I don’t know why a port
can’t be opened. I’m in the midst of working out other issues with
dhcpcd start-up though, so this could all change. I’ll consider this
local_unbound start-up problem to be a consequence of that issue,
and not currently and issue in and of itself.

Thanks all.

- Chris