k3os Config Fetched at Boot: Local config.yaml Works, Production Node Boots With Defaults

k3os reads most configuration from a cloud-config file at /var/lib/rancher/k3os/config.yaml, and that file can be supplied in more than one way. A locally installed node usually has it embedded on disk; a PXE or cloud-booted production node may instead fetch it from a remote URL named by kernel command-line parameters such as k3os.mode and its datasource options.

If the remote source is unreachable at boot, documented behavior is to continue without it, so the node starts with defaults instead of the intended hostname, SSH keys, or k3s registration arguments. Some settings also apply only on first boot or after explicit config reapplication, so a config validated in a local VM with console access is not equivalent to one applied on an already-initialized production disk.

Version sensitivity across the 0.x releases and the project's archived status add another layer: pinning the final release and migrating to a supported successor are both plausible, and the tradeoff is unresolved.

Which config source did the node actually use? Does the on-disk config match the intended one? And for a project no longer maintained, is pinning or migrating the better operational default?