Date: Sat, 14 Jul 2018 13:12:29 +0200 From: Martin Husemann <mar...@duskware.de> Message-ID: <20180714111229.gf3...@mail.duskware.de>
| In userland, dhcpcd hooks should set the full name by default, if I read | /libexec/dhcpcd-hooks/30-hostname correctly, not sure what goes wrong here | for John. I think the cause relates to the way that need_hostname() works in that file. Two things are clear ... if the host has no hostname set (or no meaningful one, "localhost", etc, don't count), of if the dhcpcd.conf variable "force_hostname" is set to true (or yes), then (assuming no other settings contradict things) then the hostname will get set (and default to the fqdn). So, for John, putting env force_hostname=YES (or true) in /etc/dhcpcd.conf should make things work as desired. It would not hurt to also include env hostname_fqdn=YES to force setting the FQDN, though that one should be the default if nothing else overrides it. The reason I suspect that works when not netbooted, is that in that case, nothing has yet set the hostname (since John said he has no hostname= in rc.conf) and so need_hostname() returns true., and the hostname gets set. But when a hostname has been set already, and force_hostname is not set (or is set to false, or something) then we get to the somewhat convoluted logic lower down in need_hostname() But in that, it tests of either old_fqdn or old_host_name are set, which if I guess correctly, means that dhcpcd has previously set the host name. Here, it has not (the kernel did) so both of those should be empty. When dhcpcd has not set the hostname, and there is a hostname, need_hostname() returns false, and nothing gets set. (That's that final "false" in the else clause right near the end of need_hostname()). I suspect this is to handle the case where the hostname has been set by some other agency (like hostname= in rc.conf, or just by some user running the hostname command). In that case, by default, dhcpcd does not override the other setting. Here it was the kernel dhcp client that set the hostname, not dhcpcd, so dhcpcd is justg leaving things alone. Similarly, in the case that dhcpcd has previously set a hostname (old_fqdn or old_host_name is not null) the script checks to see if the current hostname set in the kernel is the same (actually, to me, it looks like it just checks that it is likely the same, rather than definitely, but I might be misreading those cases) as the one dhcpcd previously set, and refuses to alter it if something else has changed it. kre