In systems that use systemd and have a current (17.0+) version of cloud-init, upstream documentation describes the process for disabling cloud-init with either of the following:
touch /etc/cloud/cloud-init.disabled
- add
cloud-init=disabled
to the kernel command line.
For older versions of cloud-init (0.7.X) the following information might be useful.
You can disable cloud-init's modification of /etc/fstab in one of 2 ways.
a.) by providing cloud-config that overrides the default 'mounts' entries and disables them.
mounts:
- [ephemeral0, null]
- [swap, null]
b.) by disabling the mounts
module from running. This is done by removing it from the 'cloud_config_modules' list that you'll see in /etc/cloud/cloud.cfg
.
With regard to hostname, you can also control that also. If you just want to stop cloud-init from modifying /etc/hostname, then:
preserve_hostname: true
Also interesting to you might be manage_etc_hosts
.
Both of these are documented in doc/examples/cloud-config.txt (and installed in /usr/share/doc/cloud-init/examples
)
I'm interested in knowing how cloud-init is breaking /etc/fstab, though. Please file a bug using ubuntu-bug cloud-init
from inside your instance, and describe what it is doing that you think is wrong.
It appears that you need to set /etc/hostname
to localhost
in order for the DHCP hostname to be considered. See context_update_kernel_hostname()
in hostnamed (https://github.com/systemd/systemd/blob/master/src/hostname/hostnamed.c#L267).
If you've already removed any hostname
lines from /var/lib/cloud/seed/nocloud[-net]/user-data
then cloud-init shouldn't be messing with the hostname anymore. Make sure you also run sudo cloud-init clean
to remove any cached data from cloud-init.
Best Answer
You can configure getty@.service to wait until cloud-init.target has finished. Same concept as this answer, but waiting for network.target didn't work for me with the cloud-init messages.