Comment # 5 on bug 1172413 from Ignaz Forster

The problem with our appliance images is that their configuration sources are
dynamic: The configuration may either be retrieved from a physical device such
as a USB flash drive (customized behavior for openSUSE) or from the platform
provider specified in `ignition.platform.id` (upstream functionality). The
platform providers in turn are implemented in a way that they won't error out
if the provider is reachable, but doesn't provide a configuration - after all
this is a valid use case.
We *could* ship our images with the `file` provider to provoke a hard fail if
the file isn't there, but then it wouldn't be possible to use the platform
specific configuration locations of QEMU, VirtualBox, VMWare etc. any more.
This could be solved by supporting multiple platforms (that's basically what
would be required for bug 1149701), but at least a year ago there was no
interest in it - we may try again though.

To sum it up from a technical perspective: With Ignition as it currently is
it's not possible to determine whether a configuration has been applied or not.
My suggestion to use the `file` provider will only work with customized
systems, but not generic images.

This problem however could be solved completely differently: With Fedora CoreOS
is is made very clear that administrators will have to provide the Ignition
file beforehand, and their documentation to do so is imho way better than ours
- just have a look at
https://docs.fedoraproject.org/en-US/fedora-coreos/getting-started/ (or the
nice download list on
https://getfedora.org/de/coreos/download?tab=metal_virtualized&stream=stable).
Placing such a hint directly next to the download links would make MicroOS way
easier to use for newcomers.

By the way: You don't have to redeploy just to trigger Ignition again: Just add
`ignition.firstboot` to the boot command line as soon as you have the
configuration ready.