Re: MulticastDNS Responder Hostname in Early Boot

[Justin Brown <Justin.Brown@xxxxxxxxxxxx>]

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@xxxxxxxxx> wrote:

On Mon, Apr 29, 2024 at 9:16 AM Justin Brown <Justin.Brown@xxxxxxxxxxxx> 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