Stop cloud-init from hanging your first boot when the metadata service is unreachable

Technical Briefing | 8/17/2026

You spin up a new node, point it at a cloud provider, and wait. And wait. The console shows the boot process hanging for minutes, completely unresponsive, while cloud-init tries to talk to a metadata service that either isn’t there or is misconfigured. I have seen this drag a five-second boot time into a five-minute funeral.

Stop the default timeout madness

Cloud-init defaults to waiting indefinitely or for absurdly long intervals because it assumes it will eventually find a DataSource. If you are building immutable images for a local lab or a private environment where no metadata service exists, you are just throwing away uptime. You need to tell it to give up early.

echo 'datasource_list: [ None ]' > /etc/cloud/cloud.cfg.d/99-disable-datasources.cfg

• Setting the datasource to None prevents the search logic from running entirely
• It stops the network waiting loop that stalls your early boot sequence
• This is essential when baking images for offline or static deployments

If you are shipping these images via bootc or similar immutable workflows, injecting this file at build time is the cleanest way to ensure your fleet doesn’t hiccup on startup. Don’t rely on the default behavior unless you are actually using the cloud provider’s network services. Otherwise, you’re just inviting latency where it doesn’t belong.