We have all been there. You spin up an immutable image or a bootc-managed node, and it sits there, waiting for network metadata that never arrives because your DHCP handshake timed out. Cloud-init is fantastic until the underlying networking stack decides to take a coffee break. When that happens, the system hangs at the boot phase or, worse, finishes booting into an unconfigured, isolated state that you have to fix manually.

Why waiting forever is the wrong default

Most cloud images ship with defaults that basically tell the OS to hold its breath until the network is perfect. If your network interface flaps or your metadata service is under load, cloud-init might just hang your deployment process for minutes. You do not want your immutable OS update to stall because a single cloud provider API request timed out.

echo 'network: {config: disabled}' > /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg

• Use the disable config to push networking responsibility to the base OS or your NMState manifests
• Avoid relying on cloud-init for interface persistence on immutable images
• Check /var/log/cloud-init.log for early boot hangs that aren’t reported to systemd

Instead of letting cloud-init fight for control of your interfaces, handle networking at the image build stage using bootc or NetworkManager profiles. If you treat your network config as part of the immutable filesystem, it cannot disappear or get mangled during the init process. It’s one less moving part to debug when the server refuses to talk to the rest of your fleet.

Next time you are baking a custom image, strip out the generic cloud-init network configuration entirely. Let the runtime handle the interface discovery, and keep your boot process predictable. You’ll thank yourself the first time your node comes back up in seconds instead of timing out.