Re: install/59573: 11.0_BETA install leaves behind /etc/rc.conf.bak.* files

["Steve Rikli via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR install/59573; it has been noted by GNATS.

From: Steve Rikli <sr%genyosha.net@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: install/59573: 11.0_BETA install leaves behind
 /etc/rc.conf.bak.* files
Date: Tue, 5 Aug 2025 08:24:47 -0700

 On Tue, Aug 05, 2025 at 09:10:02AM +0000, Martin Husemann via gnats wrote:
 >  It happens whenever we try to remove "hostname" or "defaultroute" from
 >  /etc/rc.conf and there is no such variable in there (like as you describe
 >  in a setup where DHCP failed and you enter the hostname manually).
 
 I can't follow the code but the explanation sounds reasonable.
 
 I do wonder if there is also(?) some underlying issue with dhcpcd.
 
 Experimenting further, I discovered I can replicate the problemm
 conditions simply by netbooting netbsd-INSTALL.gz, and autoconfigure
 network at some point during sysinst; it doesn't happen if I boot from
 local install media e.g. ISO mounted in the VM's virtual CD/DVD drive.
 
 I suspect the cause is sysinst / dhcpcd has trouble when it tries to
 configure an already-configured network interface.  Something happens
 in dhcpcd to prevent receiving(?)/setting the hostname, at least.
 
 An error message goes by during the network autoconfigure step, the
 screen clears and refreshes so it's not easy to catch, but it comes
 after a message about "sending Router Solicitation", and I was able
 to transcribe most of it; I think it's this:
 
 ...
 wm0: leased 172.16.0.169 for 43200 seconds
 wm0: leased 172.16.0.169 for 43200 seconds
 wm0: renew in 21600 seconds, rebind in 37800 seconds
 wm0: renew in 21600 seconds, rebind in 37800 seconds
 wm0: writing lease: /var/db/dhcpcd/wm0.lease
 wm0: writing lease: /var/db/dhcpcd/wm0.lease
 wm0: IP address 172.16.0.169/24 already exists
 wm0: IP address 172.16.0.169/24 already exists
 wm0: keeping route to 172.16.0.0/24
 wm0: keeping route to 172.16.0.0/24
 wm0: adding default route via 172.16.0.1
 wm0: adding default route via 172.16.0.1
 wm0: executing: /libexec/dhcpcd-run-hooks BOUND
 wm0: executing: /libexec/dhcpcd-run-hooks BOUND
 wm0: Invalid hostname: vm09.home.genyosha.net
 forked to background
 forked to background
 assertion "ifp != NULL" failed: file "/usr/src/lib/libc/net/getifaddrs.c", line 303 function "_freeifaddrs"
 
 That "invalid hostname" line seems pretty suspicious, even though that's
 the hostname being correctly provided by the local ISC DHCP server.  I
 don't know why most of the messages are repeated.
 
 Re-tried autoconfigure network step after sets are extracted, still no
 hostname set, and sysinst briefly shows these messages before the screen
 redraws:
 
 sending signal HUP to pid 510
 sending signal HUP to pid 510
 assertion "ifp != NULL" failed: file "/usr/src/lib/libc/net/getifaddrs.c", line 303 function "_freeifaddrs"
 
 The assertion error looks the same as from the first set of messages.
 
 FYI pid 510 in that case was:  dhcpcd: wm0 [ip4] [ip6]
 
 An indicator that something has gone wrong during autoconfigure is the
 sysinst prompt to set the hostname is empty -- no pre-filled-in value.
 If NetBSD had successfully set the hostname received from DHCP server by
 that point, there would be a hostname value in that sysinst prompt.
 
 Is this a separate bug from the rc.conf.bak.* cleanup issue?
 
 
 I'll also mention that sysinst lets me not enter a hostname (i.e. just
 hit [Enter]), which put this setting in rc.conf:
 
 hostname=.home.genyosha.net
 
 sysinst presumably tried to join "" and ".home.genyosha.net" (the
 correct DNS Domain there) into a fqdn, getting an invalid result. This
 can cause problems e.g. with postfix startup, among other things.
 
 If I reconfigure my DHCP server to not send domain-name or domain-search,
 sysinst allows blank Host Name and DNS Domain, resulting in rc.conf with:
 
 hostname=
 
 which is actually better, since dhcpcd presumably handles setting the
 hostname at that point.
 
 Is this a different bug too?