Our team works with a custom, barebone linux distro for an embedded device, and it uses systemd.
The system used to rely on SystemV init scripts until stuff got migrated to systemd (including network services.)
What we notice is that upon a reboot or boot up, systemd ignores the static hostname in /etc/hostname, and instead sets up a transient hostname equal to 'localhost'.
This is what we see at startup.
[ 2.662439] systemd[1]: No hostname configured.
[ 2.667050] systemd[1]: Set hostname to <localhost>.
But /etc/hostname is properly set, and we can set the hostname (permanent or transient) with hostnamectl no problem.
It's only when the system is rebooted that systemd ignores /etc/hostname and sets a transient hostname to localhost.
According to systemd/hostname documentation, systemd should be reading the static hostname:
systemd(1) and the associated tools will obtain the hostname in the following ways:
- If the kernel commandline parameter systemd.hostname= specifies a valid hostname, systemd(1) will use it to set the hostname during
early boot, see kernel-command-line(7),- Otherwise, the "static" hostname specified by /etc/hostname as described above will be used.
- Otherwise, a transient hostname may be set during runtime, for example based on information in a DHCP lease, see
systemd-hostnamed.service(8). Both NetworkManager and
systemd-networkd.service(8) allow this. Note that
systemd-hostnamed.service(8) gives higher priority to the static
hostname, so the transient hostname will only be used if the static
hostname is not configured.- Otherwise, a fallback hostname configured at compilation time will be used ("localhost").
However, it's falling back to the hostname configured at compilation time ("localhost").
Any ideas why this could be happening, and where to look?
The transient hostname is being set way before all the other services come into play.
Thanks.