Debian preseed and Ubuntu autoinstall: two automated-install formats, not interchangeable

What it is

Debian's debian-installer is automated with a preseed file, a plain-text list of debconf question/answer pairs. The Debian Installation Guide says to first "create a preconfiguration file and place it in the location from where you want to use it": the initrd, the boot media or the network.

Ubuntu Server (20.04 and later) and Ubuntu Desktop (23.04 and later) use a different installer, Subiquity, automated with the autoinstall format instead. Canonical's documentation states that "Automatic Ubuntu installation is performed with the autoinstall format," also called "unattended", "hands-off" or "preseeded" installation. The last of these names does not mean it uses Debian's preseed format. Autoinstall is delivered either as cloud-init user-data (a #cloud-config file with the directives under a top-level autoinstall: key, starting with version: 1) or as an autoinstall.yaml file at the root of the installation medium. If several are present, Subiquity uses the first one it finds in this order: the kernel command line (subiquity.autoinstallpath=), the root of the installation system, cloud-config, then the medium. Unless autoinstall is on the kernel command line, the installer stops for a "Continue with autoinstall?" confirmation before it writes to disk.

Why it matters

A Debian preseed file does not work on an Ubuntu install medium, and an autoinstall file does not work on Debian: the installers, schemas and delivery mechanisms all differ. Teams that build both distributions need two separate automation artifacts.

How to apply

• For Debian, start from the example preconfiguration file for the target release and edit the answers needed (partitioning, network, package selection, an optional preseed/late_command). Deliver it as preseed.cfg in the initrd, or point to it with preseed/file= or preseed/url= (short form url=) on the boot line.
• For Ubuntu, serve the cloud-config to the installer's own cloud-init, usually through the NoCloud datasource, or put autoinstall.yaml on the medium. Ubuntu cloud images do not run Subiquity; they are configured with plain cloud-init user-data.
• Validate an Ubuntu autoinstall file before relying on it: Canonical's documentation states that "Autoinstall config is validated against a JSON schema during runtime before it is applied," and the same check can be run beforehand with scripts/validate-autoinstall-user-data.py from a clone of the Subiquity repository (add --no-expect-cloudconfig for a media-delivered file, and never run it with sudo).
• For Debian, check the file's format with debconf-set-selections -c preseed.cfg, as the installation guide suggests. This checks syntax only, not whether the answers fit the release, so still test-install into a virtual machine.

Pitfalls

• Expecting the same behavior on missing answers: debian-installer stops and asks, while autoinstall takes the default for any unanswered question, or fails if there is none, unless a section is marked interactive-sections.
• Trusting schema validation too far: it checks required keys and data types but, per Canonical, "does not guarantee total validity of the data provided".
• Reusing a preseed or autoinstall file across major releases without re-checking it; both formats evolve between releases and old files can reference removed or renamed options.