Where the installer looks for a seed#

On a live boot the installer looks for a seed before it draws anything. Finding one means the machine installs itself with nobody at the keyboard. The search is wheelhouse-autoinstall, which is a program in its own right: it prints the path of an answer file and exits 0, or exits 1 to say a person should do this. It writes to no disk.

bash

sudo wheelhouse-autoinstall          # just say which seed would be used
sudo wheelhouse-install --seed       # find one and use it

The four sources, in order#

The search stops at the first seed it finds.

1. The kernel command line#

wheelhouse.autoinstall=<value>:

Value	Means
`off`, `none`, `no`, `disabled`	Do not autoinstall. Exit 1 immediately.
`https://…`	Fetch the seed from that URL.
`http://…`, `ftp://…`	Refused unless `wheelhouse.insecure=1` is also given.
`label:NAME`	Mount the filesystem with that label and look inside.
`/dev/sdb1`	Mount that device and look inside.
`/some/path`	Use that file on the live image directly.
`auto`, or empty	Carry on with the normal search below.
anything else	Logged as `wheelhouse.autoinstall=X means nothing to me`, and the search continues.

2. A labelled filesystem#

Any partition labelled WHEELHOUSE or CIDATA — cloud-init's NoCloud name — is mounted read-only and searched, in that order and in both cases:

WHEELHOUSE  wheelhouse  CIDATA  cidata

Inside, the top level and a wheelhouse/ subdirectory are searched for these names:

wheelhouse.conf   wheelhouse.yaml   wheelhouse.yml   user-data

Names are matched without regard to case, and with the version suffix ISO 9660 adds (USER-DATA.;1), because a seed built with plain mkisofs looks like that. The search stops at the first match: printing two paths would hand the installer a two-line answer.

3. cloud-init's own seed#

When cloud-init has already found one, these three directories are searched with the same file names:

/var/lib/cloud/seed/nocloud
/var/lib/cloud/seed/nocloud-net
/var/lib/cloud/instance

4. Baked into the image#

/usr/share/wheelhouse/autoinstall.conf. Nothing ships one; it is for images built to install a fleet the same way every time.

The three kernel parameters#

Parameter	Effect
`wheelhouse.autoinstall=<value>`	Names the seed, or switches the search off. See the table above.
`wheelhouse.autoinstall.sha256=<hex>`	Pins the content of a fetched seed. The download is hashed and discarded if it does not match, naming what it got.
`wheelhouse.insecure=1`	Says the network is trusted, and means it: plain `http://` and `ftp://` seeds and payloads are then fetched.

Once per boot#

/run/wheelhouse-autoinstall.attempted

The installer creates that file the moment it adopts a seed, before it does anything else. If the unattended install cannot finish, the next start of the installer sees the file, logs an autoinstall already ran this boot; leaving this one to a person, and shows the menu instead of erasing a disk again.

/run is a tmpfs, so a reboot clears it — which is why the second guard exists.

It will not reinstall an installed machine#

Before it touches anything, a seeded install checks whether the target disk already holds a system, by looking for a partition labelled persistence or an ext4 partition carrying a boot/*/rw/opt/vyatta tree. If it does, and the seed did not say overwrite: true:

/dev/sda already holds an installed system, and the seed did not ask to overwrite it.
Leaving the disk alone. Remove the seed medium, or set 'overwrite: true' in it to reinstall.

The installer then falls back to the interactive menu. The common way to meet this is the seed medium left plugged in and the machine rebooted; erasing the install it had just made would be the worst possible reading of "unattended".

Together with the once-per-boot rule, a seed cannot become a loop that keeps erasing the same disk.

What "adopting" a seed does#

For each candidate, wheelhouse-autoinstall runs seed-to-answers.py into /run/wheelhouse-seed/, and accepts the result only if it contains at least one ^[A-Z_]+= line. Anything else is logged as X is not a usable seed and the search continues. Payload files the seed names — config.commands, config.boot, authorized_keys — are copied into the same directory, so they are still readable once the medium is unmounted.

The accepted path, /run/wheelhouse-seed/answers.conf, is printed on stdout. That is the whole interface between the two programs.

Waiting for the agent#

Before drawing anything, an --auto or --seed run waits up to five minutes (60 × 5 s) for wheelhouse-agent to become active, because the installer sets the web UI password through the agent's API. On a console it shows a "Wheelhouse is starting" box with a running count; under --seed it prints a one-line ticker to stderr.

Where it logs#

Every step, in /var/log/wheelhouse-install.log, prefixed autoinstall:. Run the finder with VERBOSE=1 to see the same lines on stderr: