Upgrading from 14.4 to 15 causes breakage

[bob2112]

Not sure it's the case or not, but this wouldn't work if local-unbound is up and running. (In case you have local_unbound_enable="YES" in your /etc/rc.conf.)
It automatically and forcibly comments out all existing nameserver entries in /etc/resolv.conf and put nameserver 127.0.0.1 and options edns0 lines at the end

But once it's done that, if you edit resolv.conf and put in your own nameserver lines, local_unbound is bypassed as long as the change doesn't get reverted. In my experience that doesn't routinely happen, at least not with static IP addresses.

 

[SirDice]

Unless you can give me the commands to run to check.

Besides a bunch of error messages does the system still boot? Once booted what does freebsd-version -urk show? I need to know how far the upgrade process was done, freebsd-update install doesn't require network access (everything it needs is already downloaded with freebsd-update {...} upgrade) so this should work even if you disconnect the entire host from the network.

And have a look in /boot/loader.conf, specifically look for lines that look like if_<interface>_updated_load="YES".

Best to try by commenting almost everything in rc.conf, don't start any services, strip it down to the bare minimum (setting IP addresses, hostname, and sshd for example). The less there's running while doing the upgrade the better. It can all produce a bunch of scary looking error messages if you're half way through the upgrade.

 

[T-Aoki]

But once it's done that, if you edit resolv.conf and put in your own nameserver lines, local_unbound is bypassed as long as the change doesn't get reverted. In my experience that doesn't routinely happen, at least not with static IP addresses.

If you DON'T have local_unbound_enable="YES" in your /etc/rc.conf, this does not matter.

What I've experienced before with local_unbound_enable="YES" was that /etc/resolve.conf was updated again (commented out nameserver entries) on restart (regardless manually or after actual reboot) if any changes to /etc/resolve.conf were made.

Most notablly, when I've disconnected from wired home LAN and connected WiFi outside home, then back to home and reconnected to wired home LAN, no hostnames other than ones in /etc/hosts could be resolved.

This was because /var/unbound/forward.conf was updated to use the DNS supplied on the DHCP server of the WiFi was unavailable outside the WiFi network and I've NOT manually edited neither /etc/resolve.conf nor /var/unbound/forward.conf for home LAN, thus, no usable DNS server was available.

Not sure it still matters, though, as I'm not using other than wired LAN with fixed IP addresses for years.

 

[bob2112]

What I've experienced before with local_unbound_enable="YES" was that /etc/resolve.conf was updated again (commented out nameserver entries) on restart (regardless manually or after actual reboot) if any changes to /etc/resolve.conf were made.
...
This was because /var/unbound/forward.conf was updated to use the DNS supplied on the DHCP server of the WiFi was unavailable server was available.

This is why I wrote "at least not with static IP addresses". The key thing though, is that if you have a networking problem and still have only well known addresses in resolv.conf, local_unbound is not relevant.