Autoinstall is Ubuntu Server's unattended-install format, used by the Subiquity installer since 20.04. It replaced the Debian-installer/preseed approach on Ubuntu (Debian itself still uses Preseed) and is built directly on cloud-init's user-data mechanism, which is why its syntax looks like cloud-init rather than like Kickstart.
Structure¶
An autoinstall config is YAML under an autoinstall: key, typically delivered as cloud-init user-data:
#cloud-config
autoinstall:
version: 1
locale: en_US.UTF-8
keyboard:
layout: us
network:
network:
version: 2
ethernets:
eth0:
dhcp4: true
storage:
layout:
name: lvm
identity:
hostname: server01
username: admin
password: "$6$roundsaltedhashhere"
ssh:
install-server: true
authorized-keys:
- ssh-ed25519 AAAA...
packages:
- chrony
- vim
late-commands:
- curtin in-target -- systemctl enable chronyd
user-data:
disable_root: true
Key sections, at a glance:
| Key | Purpose |
|---|---|
storage |
partitioning/LVM layout — lvm, direct, or a full custom config: list |
identity |
hostname, primary user, password hash |
ssh |
install openssh-server and seed authorized keys |
packages |
extra packages beyond the base install |
early-commands / late-commands |
shell commands run before/after install (roughly Kickstart's %pre/%post) |
user-data |
passed straight through to cloud-init for first-boot config on the installed system |
Interactive sections and confirmation¶
By default, any section you don't specify falls back to interactive prompts. Add interactive-sections: [] to make everything unattended, or list specific sections (e.g. interactive-sections: [network]) to leave just those prompted. For fully hands-off installs on real hardware, autoinstall also normally shows a final confirmation prompt unless you boot with the autoinstall kernel parameter (see below), which is a deliberate safety guard against accidentally wiping a disk from a config meant for a different machine.
Validate before using¶
sudo snap install subiquity --classic # or: sudo apt install subiquity (varies by release)
python3 -c "import yaml, sys; yaml.safe_load(open('autoinstall.yaml'))" # basic YAML sanity check
cloud-init schema --config-file autoinstall.yaml # validates the cloud-init/autoinstall schema itself
Delivering the config¶
# Local ISO build (nocloud datasource via a second attached volume/ISO)
# a genisoimage-built "cidata" volume containing user-data + meta-data, attached as a CD-ROM
genisoimage -output seed.iso -volid cidata -joliet -rock user-data meta-data
# Boot the Ubuntu Server ISO with the autoinstall kernel parameter and a datasource pointing at the seed:
# autoinstall ds=nocloud;s=/cdrom/ (when the seed is a second attached ISO)
# autoinstall ds=nocloud-net;s=http://<server>/autoinstall/ (served over HTTP, good fit for PXE)
The ds=nocloud-net;s=http://... form is the one that pairs cleanly with PXE/netboot: the installer fetches user-data and meta-data from that HTTP path the same way it would from a cloud-init metadata service.
Relationship to cloud-init¶
Autoinstall's user-data: block (nested inside the autoinstall document) is handed to cloud-init verbatim once the base OS is installed and boots for the first time — so anything you'd normally configure with plain cloud-init (extra users, write_files, runcmd) works there too. Think of Autoinstall as "cloud-init's config format, extended with a storage/network/identity vocabulary for driving the actual OS installer," rather than a separate, unrelated tool.