[systemd-devel] MulticastDNS Responder Hostname in Early Boot

[Justin Brown]

Yes, all of the command output was run within the initramfs, not the fully
booted system. /etc/hostname exists in the initramfs.

I ran a couple of tests using systemd.hostname as a kcmdline parameter:

=> cat /etc/hostname
testvm
=> cat /proc/cmdline
bgrt_disable systemd.hostname=testvm
=> journalctl -u systemd-resolved.service
Apr 29 13:57:36 testvm systemd-resolved[109]: Positive Trust Anchors:
Apr 29 13:57:36 testvm systemd-resolved[109]: . IN DS 20326 8 2
e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
Apr 29 13:57:36 testvm systemd-resolved[109]: Negative trust anchors:
home.arpa 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa
18.172.in-addr.arpa 19.172.in-addr.arpa 20.172.in-addr.arpa
21.172.in-addr.arpa 22.172.in-addr.arpa 23.172.in-addr.ar>
Apr 29 13:57:36 testvm systemd-resolved[109]: Defaulting to hostname
'archlinux'.
Apr 29 13:57:36 testvm systemd[1]: Started Network Name Resolution.

=========

=> cat /etc/hostname
testvm
=> cat /proc/cmdline
bgrt_disable systemd.hostname=testvm2
=> hostname
testvm2
=> cat /proc/sys/kernel/hostname
testvm2
=> journalctl -u systemd-resolved.service
Apr 29 14:17:15 testvm2 systemd-resolved[109]: Positive Trust Anchors:
Apr 29 14:17:15 testvm2 systemd-resolved[109]: . IN DS 20326 8 2
e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
Apr 29 14:17:15 testvm2 systemd-resolved[109]: Negative trust anchors:
home.arpa 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa
18.172.in-addr.arpa 19.172.in-addr.arpa 20.172.in-addr.arpa
21.172.in-addr.arpa 22.172.in-addr.arpa 23.172.in-addr.a>
Apr 29 14:17:15 testvm2 systemd-resolved[109]: Defaulting to hostname
'archlinux'.

I didn't originally notice, but look at the journalctl output.
Systemd-journald knows the correct hostname in both examples in this email
and also in my original email. The journal is not using the compiled
fallback hostname (archlinux). So even in the initramfs, the hostname is
set properly and parts of systemd are picking up the correct information.
Systemd-resolved isn't getting that information, though, and uses the
compiled fallback hostname. I think the core of the problem is that
systemd-resolved doesn't try to read the kernel hostname, and is solely
reliant on querying the hostname through dbus.

I forgot to include version information in my original post:
glibc 2.39-2
linux 6.8.7.arch1-2
systemd 255.5-2

Thanks,
Justin

On Mon, Apr 29, 2024 at 6:29 AM Mantas Mikulėnas <grawity at gmail.com> wrote:

> On Mon, Apr 29, 2024 at 9:16 AM Justin Brown <Justin.Brown at fandingo.org>
> wrote:
>
>> Hello,
>>
>> I'm having some trouble the resolved as a multicast DNS responder in
>> early boot. I'm trying to setup a headless system with full disk
>> encryption, and I need to connect remotely (currently using tinyssh) to
>> unlock sysroot and other volumes before the boot continues. I use networkd
>> to setup the dhcp interface, which works fine. The problem is that resolved
>> won't use the value in /etc/hostname, and I can't find a resolved or
>> networkd option to specify a hostname.
>>
>
> Does your initramfs actually contain /etc/hostname? resolved will use the
> value that's been set as the *kernel* hostname.
>
> Usually the loading of /etc/hostname into the kernel hostname is done by
> systemd, and if it hasn't done so then I'm guessing the file is not part of
> the initrd...
>
> (But you can use "/bin/hostname -f" or "sysctl kernel.hostname" or "echo
> testvm > /proc/sys/kernel/hostname" or pass "systemd.hostname=testvm" as a
> kernel command line option to achieve the same thing.)
>
> --
> Mantas Mikulėnas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20240429/1f3552b7/attachment.htm>