Question
hostname field in k3os v0.12.0 cloud-config requires two boots to apply
Ari Nova
0 reputation · 25 Jan 2025, 18:12 UTC
49.7K views
Loading…
0 reputation · 25 Jan 2025, 18:12 UTC
Goal: Ensure that the hostname specified in a k3os cloud‑config is available to the k3s service during the first boot so that nodes register with Rancher using the correct identifier without requiring a manual reboot or cfg apply.
Constraint: In k3os v0.12.0 the hostname key is handled by systemd‑hostname after network‑online.target, while k3s.service starts early and therefore sees the temporary 'k3os' hostname. The documented behavior notes that the hostname field is only honored on the second boot after a reboot or after running sudo k3os cfg apply, leaving the timing and supported work‑arounds unclear.
Questions:
32775 reputation · 26 Jan 2025, 01:32 UTC
In k3os v0.12.0 the hostname field in cloud‑config is processed by cloud‑init during the first boot. Cloud‑init writes the requested name to /etc/hostname, but the active system hostname (as seen by hostnamectl or the hostname command) is not updated until the next boot because systemd‑hostname only reloads the file at early boot and does not react to runtime changes.
The delay is not a bug in k3os but a consequence of how systemd‑hostname works: it reads /etc/hostname once during init and then relies on the kernel’s hostname setting. Changing the file later does not trigger an automatic update unless a service like systemd-hostnamed is explicitly invoked (e.g., via hostnamectl set-hostname) or the machine is rebooted.
k3s
k3osruncmd that immediately sets the hostname after cloud‑init has written the file:runcmd:
- [hostnamectl, set-hostname, mydesiredhost]
k3s.service that orders it after systemd-hostname.service:# /etc/systemd/system/k3s.service.d/hostname.conf
[Unit]
After=systemd-hostname.service
Wants=systemd-hostname.service
sudo systemctl daemon-reload
sudo systemctl restart k3s.service
hostname # should show mydesiredhost
If you cannot modify the k3s.service unit (e.g., the node is immutable), please confirm whether you have permission to add a runcmd
Use comments to ask for clarification. Post a solution as an answer.
32,775 reputation · 26 Jan 2025, 03:22 UTC
In v0.12.0, cloud‑config writes the desired name to /etc/hostname during the first boot, but systemd-hostname.service reads that file only once at init. If k3s.service starts before that unit finishes, the kernel still holds the image’s default hostname.
systemctl list-dependencies k3s.service to see if systemd-hostname.service is listed before the k3s unit.runcmd that calls hostnamectl set-hostname after cloud‑init, but note that the change is only effective for the current boot unless the unit is reordered.