obmc-targets: remove RefuseManualStop

Per freedesktop.org, this option is "mostly a safety feature to ensure
that the user does not accidentally activate units that are not
intended to be activated

obmc-targets: remove RefuseManualStop

Per freedesktop.org, this option is "mostly a safety feature to ensure
that the user does not accidentally activate units that are not
intended to be activated explicitly".

There have been a few instances when doing some systemd debugging, that
the ability to manually stop these targets would be useful. Given that
the only users logged into the BMC should know what they're doing, this
should not be much of a concern.

IBM has a tool called "istep" which can be used to boot the host
firmware independently from the different openbmc targets and services.
It's primarily used by the chip design and bringup team to have more
fine grained control over the initialization of the host hardware. The
problem with using istep is that it does not start any systemd targets
to boot the host firmware, but it does depend on systemd targets to
power the system off. The issue here is that if you don't start the
targets to boot the system, their "Conflicts" will not stop
the targets used to power down the system. When that doesn't happen,
there is no synchronization provided by those targets because they are
already running.

The solution will be to provide a shell script that istep (or any other
independent boot application) can call to manually stop all the targets
needs to synchronize the power off.

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

show more ...

bootblock: ensure no power operation on block

Systemd does not treat targets the same way it treats services. If you
start a target which has Wants/Requires, it will execute the services
associated

bootblock: ensure no power operation on block

Systemd does not treat targets the same way it treats services. If you
start a target which has Wants/Requires, it will execute the services
associated with that target before the Wants/Requires for the target
have been fulfilled. The target will not set itself as complete until the
Wants/Requires is fulfilled but this causes a weird behavior currently.

For example, if ErrorBlocksTransition interface is present on D-Bus and
the obmc-chassis-poweron@.target is started, the system will fully power
on, but the chassis power state will continue to report as off. This is
because all services were launched under the target to power on the
system but because the target does not complete, the BMC still reports
the chassis power as not being on.

The solution is to move the bootblock dependencies from target
responsible for starting all of the services to the synchronization
target that services utilize to order their execution.

Putting the bootblock dependencies in the obmc-power-start-pre@.target
ensure no power on services will be run.

Tested:
- Ensured a bootblock now stops the system from powering on

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

show more ...

multi-user: do not use wants relationship

The multi-user target is run by systemd when the BMC first boots. It
contains all of the initial startup services. Some OpenBMC targets want
to ensure they

multi-user: do not use wants relationship

The multi-user target is run by systemd when the BMC first boots. It
contains all of the initial startup services. Some OpenBMC targets want
to ensure they are run after the multi-user target completes. A lot of
these targets did both a Wants and After relationship with multi-user.

The latest systemd, version 245, now takes that Wants relationship
seriously and will start any services within multi-user that are
stopped. This includes oneshot services which do not have the
"RemainAfterExit=yes" clause. If these services only expected to be run
once, as a part of multi-user, then they should include this clause but
you can see how they may expected to have only been run once.

The solution is twofold:
1) Fix the oneshot services that fall in the above scenario
2) Change the targets to not Wants=multi-user.target

1 will be changes throughout a few repositories.
2 is fixed in this commit.

Resolves openbmc/phosphor-state-manager#14

Tested:
Provided test image to George and he verified this fixed the above
issue

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

show more ...

move openbmc targets into this repo

OpenBMC is moving towards individual repos hosting and maintaining their
own systemd files. This allows the corresponding maintainer more control
over their syste

move openbmc targets into this repo

OpenBMC is moving towards individual repos hosting and maintaining their
own systemd files. This allows the corresponding maintainer more control
over their systemd files and removes the meta-* layer maintainer from
needing to be involved.

The systemd targets defined and used by OpenBMC are implemented by
phosphor-state-manager code and services so move them into this
repository.

Once this is merged, its bump will need to be combined with a change in
the meta-phosphor layer that removes the target files.

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

show more ...