@encryptblockr said in Ubuntu 24.04 Cloud Image Template Not Working:
did you mount the guest tools cdrom to the cloud image before you created a template from it?
No, I just make my base images (for the end template) as generic as possible, and I do all mounts, package installs, accounts, keys, including the xe-guest utils package all in the user-data config for cloud-init. Makes the configurations more uniform across all stacks I have to maintain and scales really well with jinja templates.
also what is point of {name}% in below? can you explain? where does it get {name} from and what is % use?
That pulls the hostname from metadata that is provided by the nocloud datasource.
If you ever want to see all the metadata available (for example, say your provisioning plane does dynamic configuration from some backend IAS platform, and you need logic that renders metadata to run different configurations; run the following after login:
cloud-init query -a
For example, I run different configurations based on what the 'distro' value is -
example:
cloud-init query -f {{v1.distro}}
{% if distro in ['rocky', 'ol', 'centos', 'fedora', 'redhat', 'almalinux'] -%}
//do the rpm things//
This allows us to run completely different configuration settings based on what distro its being run in, or even what virtualization platform it is running on. Some platforms won't use the hostname, or fqdn meta values, so I have some if logic that only adds it when vendordata is null, example;
{% if vendordata == '' %}
fqdn: {name}
{% endif %}
Probably more than you wanted to know, but that's a brief summary of cloud-init metadata.
