Ignition silently fails to enable a nonexistent unit

Issue by @bgilbert

Issue Report

Bug

Container Linux Version

$ cat /etc/os-release
NAME="Container Linux by CoreOS"
ID=coreos
VERSION=1590.0.0
VERSION_ID=1590.0.0
BUILD_ID=2017-11-08-0831
PRETTY_NAME="Container Linux by CoreOS 1590.0.0 (Ladybug)"
ANSI_COLOR="38;5;75"
HOME_URL="https://coreos.com/"
BUG_REPORT_URL="https://issues.coreos.com"
COREOS_BOARD="amd64-usr"

Environment

Any

Expected Behavior

If Ignition is asked to enable a nonexistent unit, it fails the boot.

Actual Behavior

Ignition claims to have enabled the unit, but nothing happens.

Reproduction Steps

1. Boot the following CLC:

systemd:
  units:
    - name: blargh.service
      enabled: true

2. Check journalctl -t ignition and systemctl status.

Other Information

This happens because Ignition configures systemd units via presets, and presets are allowed to reference nonexistent units.

journalctl says:

Nov 10 01:19:32 localhost ignition[439]: files: op(8): [started]  processing unit "blargh.service"
Nov 10 01:19:32 localhost ignition[439]: files: op(8): [finished] processing unit "blargh.service"
Nov 10 01:19:32 localhost ignition[439]: files: op(9): [started]  enabling unit "blargh.service"
Nov 10 01:19:32 localhost ignition[439]: files: op(9): [finished] enabling unit "blargh.service"

Reproduce the CLC configuration with the nonexistent blargh.service unit, then inspect Ignition's systemd unit and preset handling. Use journalctl -t ignition and systemctl to compare the current behavior with the expected boot failure; done means enabling a nonexistent unit no longer succeeds silently.