Code change:
Hostname being unset (resulting in ) causes issues for logging. Specifically, with journald, the same boot (identified by (see systemd.journal-fields(7)) has both and with the switch happening at the rootfs pivot of the boot. This makes filtering by hostname difficult. Even more so, when doing log aggregation from multiple machines, filtering by hostname will yield incomplete results. Instead one must build a pipeline that makes looks up all bootids of a hostname and querying all those instead. Steps to reproduce the behavior: behavior described above journal contains the the same as long as it not changed by the user. Hostname should be generally available, even during early boot(?). N/A I'm filing this as a bug instead of a pull request because I'm not sure if there are any unintended consequences of doing this. Aside from the usual Hoping for your input here. There's a reference in the docs giving an example of setting the hostname by hand: (from ). Why this was chosen as an example and not just standard behavior, I don't know. CC/FYI , who the example/was tagged in the commit. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Me neither. I don't see a reason not to have that file. may be more knowledgeable, but I'd say go for it. Also systemd-based initrd is somewhat young, so I feel like the probability for spacebar heating is somewhat low.
I think the main reason was to have the initrds be more substitutable between different hosts as this would be a difference between all of them (when having different systems with only different hostnames). I'm not sure how well adding the hostname file would work. My memory is a bit fuzzy on the details (I did a lot of other projects at that time) but I think an issue was that when journald starts up, it imports the kernel logs BEFORE the hostname was set (causing the pre-systemd lines to be mapped to localhost). An alternative implementation that would probably solve that as well (if it's still/even an issue) would be adding the kernel parameter rather than adding the file to the initrd.
If I read the code correctly, journald reads the hostname from /proc: -: So the hostname needs to be set system-wide before journald starts up. Systemd does this in --: So on bare metal we can either set on the kernel cmdline or it seems.
It seems this is the best choice then, but maybe also as that's more standard and picked up even earlier in the boot process. Unless you're running an old kernel though. () We could just set both.
I'll run an experiment to see if even solves my problem or one must use . On that note, I also realized there's an equivalent (or slightly harder?) problem with as well :-.
(So, setting /etc/hostname in the initrd works. Every message from that boot has the correct hostname.) I was also thinking about your folks' usecase some more, and was wondering about one thing ... how are you approaching the UKI/secureboot? None of the mentioned approaches work for that, right?
Why not? Most people use for that which signs whatever UKI you have locally with a local key
Because changing files or the kernel cmdline will cause different images to be created? Your design shares a single one among multiple hosts, no?
Yes, that's the downside. Although, the cmdline is only baked into the UKI which is not in the nix store anyway. This way we could substitute the initrd and have differing hostnames. I must mention, however, that I personally don't care about the substitutability of the initrd. My main focus was to keep the state as it was before, but if people decide it's time to change that, I'm not opposed to that ;)

Related discussion:
text: description = "Set of files that have to be linked into the initrd"; example = literalExpression '' { <del> "/etc/hostname".text = "mymachine"; </del> <ins> "/etc/machine-id".source = /etc/machine-id; </ins> } ''; default = {};