remove installs on templated services and targets

New yocto is getting more stringent on installation of templated service
and targets.

Templated services are installed by bitbake recipes so there'

remove installs on templated services and targets

New yocto is getting more stringent on installation of templated service
and targets.

Templated services are installed by bitbake recipes so there's no
need to have the WantedBy/RequiredBy in those services.

Here's a summary of the error we get for packages which have templated
services doing an install:
```
ERROR: obmc-phosphor-image-1.0-r0 do_rootfs: Postinstall scriptlets of
['<package>' 'inst returned 1, marking as unpacked only, configuration
required on target']
If the intention is to defer them to first boot,
then please place them into pkg_postinst_ontarget:${PN} ().
Deferring to first boot via 'exit 1' is no longer supported.
```

Tested:
- Confirmed image builds with new yocto and services are still installed
as expected

Change-Id: I56d9ac7a73dfd6bdaa05eba39d890a8af3605d18
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>

show more ...

transition: ensure only run once per power on/off

Some situations have arisen where a user requests a power off or on when
the system is already in that state. That results in these services
re-runn

transition: ensure only run once per power on/off

Some situations have arisen where a user requests a power off or on when
the system is already in that state. That results in these services
re-running and setting the state to transition even though the system is
actually off or on already.

The solution is to ensure these services only run once and do not stop
until a Conflicts occurs to stop it.

Tested:
- Verified service only runs once now even if started multiple times
- Verified when conflicting target runs that you can start service again

Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
Change-Id: I2aa866057fca9c1743385f0d5f3beff5899e4c15

show more ...

host state transitioning support

The following commit has some relevant background:
https://github.com/openbmc/phosphor-dbus-interfaces/commit/9f65dfeaa5ab22cae03db45c9916868da9864f83

The new servi

host state transitioning support

The following commit has some relevant background:
https://github.com/openbmc/phosphor-dbus-interfaces/commit/9f65dfeaa5ab22cae03db45c9916868da9864f83

The new services introduced in this commit will set these new transition
states. They will work together with the existing state-manager
infrastructure in that the new services will set the transitions when
the targets start and the current software which looks for the targets
to complete will update the state to the official Running/Off.

But why not just have the existing software that monitors for the
targets to complete also monitor for them to start? This was a long and
dark hole I went down for a while. In the end, systemd D-Bus signals do
not provide enough information on target starts. The signals let you
know that "something" is going to happen to the target you're interested
in, but not the details. For example, if you start the
obmc-host-start@.target, you get two systemd notifications that indicate
"something" is going to happen to obmc-host-start@.target and also that
"something" is going to happen to obmc-host-stop@.target. This is
because when one target starts, it stops the other. Since they are both
just queued for "something" there's no mechanism to interrogate them for
which one is doing what. I tried a lot of different things here but
just couldn't get anything that covered all paths. The maintainers of
systemd have indicated on their mailing list that they are not
interested in enhancing the signal data because they feel like it would
be a rat hole of never ending data getting added to it.

Tested:
- Built into an image and verified CurrentHostState changed as expected
doing a host on, off, and reboot.

Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
Change-Id: Id2e9bd0394fc71944d26ce4bd40b136acf82b5e4

show more ...