remove 'flush' failure modes

The `flush` failure mode is impossible to use for a multi-host system.
If one of the services or targets fail on one host, it would cause the
pending operations for the

remove 'flush' failure modes

The `flush` failure mode is impossible to use for a multi-host system.
If one of the services or targets fail on one host, it would cause the
pending operations for the other host to be flushed from the systemd
job queue. This leaves the other hosts in an indeterminate state.

We need to use `fail` in order to allow jobs targeting other hosts to
continue operating. This triggers the OnFailure for the target(s),
including ones which are pending awaiting dependencies.

As a result of this change, we may need to tweak some of the existing
services to add correct OnFailures.

Tested: Ran on a yosemite4 image in QEMU, which always fails part of
the boot sequence due to a missing PLDM-based satellite management
controller. After a few host reboot attempts the system settles into a
stable state on all hosts.

Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: I2071219c9c139723785ba05bed18a6ff808ad565

show more ...

meson: Replace configure_file with fs.copyfile

configure_file is deprecated since 0.64.0, and replace it with
fs.copyfile.

Signed-off-by: George Liu <liuxiwei@inspur.com>
Change-Id: I9da6cfc78f1350

meson: Replace configure_file with fs.copyfile

configure_file is deprecated since 0.64.0, and replace it with
fs.copyfile.

Signed-off-by: George Liu <liuxiwei@inspur.com>
Change-Id: I9da6cfc78f1350e7d3bd755db1ecf19a23c86c5c

show more ...

Support chassis power cycle

A new system is being designed which will utilize phosphor-state-manager
and it requires the chassis system power cycle feature.

Test plan:
Change property "RequestedPow

Support chassis power cycle

A new system is being designed which will utilize phosphor-state-manager
and it requires the chassis system power cycle feature.

Test plan:
Change property "RequestedPowerTransition" to trigger
chassis power cycle target.

Change-Id: I30b0efd7c0fc72a9fb378f48e47c4c1af2b22ad6
Signed-off-by: Bonnie Lo <Bonnie_Lo@wiwynn.com>

show more ...

obmc-host-graceful-quiesce: ensure starts synch targets

As seen in other scenarios, the power off synchronization targets do not
always start in time when the obmc-host-graceful-quiesce@.target is
s

obmc-host-graceful-quiesce: ensure starts synch targets

As seen in other scenarios, the power off synchronization targets do not
always start in time when the obmc-host-graceful-quiesce@.target is
started. This can result the host being stopped before it has had the
chance to gracefully shut itself down.

Ensure the synchronization targets are started by adding them into the
target with 'Wants' relationships.

Tested:
- Booted system into hostboot, manually started the target and verified
via the journal that the pldm-softpoweroff application completed prior
to instructions stopping.

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

show more ...

host-reboot: enforce host boot count on host crash

The host reboot path can be triggered via paths outside of the normal
RequestedHostTransition property set. For example, if the host crashes,
it ju

host-reboot: enforce host boot count on host crash

The host reboot path can be triggered via paths outside of the normal
RequestedHostTransition property set. For example, if the host crashes,
it just triggers an automatic reboot using the systemd targets, which
means the check to prevent continuous host reboots is not run.

This commit ensures we decrement the reboot counter when a host crash
occurs, and it also ensures we check that count when deciding if a
reboot should occur.

While testing, it was found when we end in the host Quiesce state (after
all reboot attempts have expired), the host stayed in Quiesce, even
after issuing a power off. The fix for that was to ensure the
obmc-host-quiesce@.target conflicted with obmc-host-stop@.target to
ensure it would properly run on the power off request and update the
host state to Off.

Tested:
- Verified that AttemptsLeft was properly decremented on host crashes
- Verified that when AttempsLeft reached 0, the reboot was halted
and the host state was moved to Quiesced
- Verified that once in Quiesced, system could be powered off, and a
boot worked fine (and AttempsLeft was back to 3)

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

show more ...

Define new 'obmc-chassis-blackout@.target'

This implements a new target 'obmc-chassis-blackout@.target' that works
to signify that a blackout has occurred on the chassis. This is useful
in situation

Define new 'obmc-chassis-blackout@.target'

This implements a new target 'obmc-chassis-blackout@.target' that works
to signify that a blackout has occurred on the chassis. This is useful
in situations where the system suffers from a blackout and the user
wants behavior that differs from the default of always running APR.
It will also be attached to services such as phosphor-sensor-states that
will ensure LEDs will be powered off.

Uses the proposed target added here
https://gerrit.openbmc.org/c/openbmc/phosphor-state-manager/+/54364

Tested:
- Booted an image with the corresponding changes to the bitbake
recipe and verified that the new target was found in
"/lib/systemd/system/".
- verified the target could be called by systemctl.
- obmc-chassis-blackout@0.target - Chassis Blackout Target
Loaded: loaded (/lib/systemd/system/obmc-chassis-blackout@.target; static)
Active: inactive (dead)
- started target.
- obmc-chassis-blackout@0.target - Chassis Blackout Target
Loaded: loaded (/lib/systemd/system/obmc-chassis-blackout@.target; static)
Active: active


Signed-off-by: Corey Hardesty <corey.hardesty@icloud.com>
Change-Id: Ic7aded7213153e7ee0d711e02368680ae72d08a8

show more ...

host-graceful-quiesce: introduce new target

Per design here:
https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/52874

This introduces a new target which can be started to gracefully quiesce
the h

host-graceful-quiesce: introduce new target

Per design here:
https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/52874

This introduces a new target which can be started to gracefully quiesce
the host. This allows the host an opportunity to shut itself down
gracefully.

Tested:
- Built image with new target and included pldmSoftPowerOff.service in
it so that host firmware got a chance to gracefully shut down prior to
Quiesce.

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

show more ...

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 ...

crit-service: start bmc quiesce target on fail

This target will be monitored by the BMC state target and used to tell
external clients when the BMC is in a bad state due to a critical
service failin

crit-service: start bmc quiesce target on fail

This target will be monitored by the BMC state target and used to tell
external clients when the BMC is in a bad state due to a critical
service failing

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

show more ...

Remove obmc-mapper.target

The obmc-mapper.target is the common target for OpenBMC and shall be
installed by default.
However, this repo is not installed by systems that use
x86-power-control. So the

Remove obmc-mapper.target

The obmc-mapper.target is the common target for OpenBMC and shall be
installed by default.
However, this repo is not installed by systems that use
x86-power-control. So the obmc-mapper.target will be moved to the
openbmc repo in a separate patch.

Signed-off-by: Lei YU <yulei.sh@bytedance.com>
Change-Id: Ifeae9783d20329dc85847fce393945cd932e4cbe

show more ...

clarify power stop and start targets

Currently you see this in the journal:

Jan 26 20:59:28 witherspoon-Y230UF71K03T systemd[1]: Reached target Power0 Off (Pre).
Jan 26 20:59:30 witherspoon-Y230UF7

clarify power stop and start targets

Currently you see this in the journal:

Jan 26 20:59:28 witherspoon-Y230UF71K03T systemd[1]: Reached target Power0 Off (Pre).
Jan 26 20:59:30 witherspoon-Y230UF71K03T systemd[1]: Reached target Power0 Off.
Jan 26 20:59:30 witherspoon-Y230UF71K03T systemd[1]: Reached target Power0 (Off).

The last two are a bit confusing so enhance the description of the start
and stop synchronization targets to clearly show they are coordinating
the activity, not at the final destination. Now we'll get this:

Jan 26 20:59:28 witherspoon-Y230UF71K03T systemd[1]: Reached target Power0 Off (Pre).
Jan 26 20:59:30 witherspoon-Y230UF71K03T systemd[1]: Reached target Power0 Off (Starting).
Jan 26 20:59:30 witherspoon-Y230UF71K03T systemd[1]: Reached target Power0 (Off).

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

show more ...

ensure synch targets started by execution targets

Some systemd services within OpenBMC are run in multiple targets, or
sometimes in standalone situations. When those services are run as a
part of a

ensure synch targets started by execution targets

Some systemd services within OpenBMC are run in multiple targets, or
sometimes in standalone situations. When those services are run as a
part of a target, they sometimes need to ensure they run before or after
a synchronization target. They can utilize the Before/After directive
for this but they need assurance the target has been started (i.e.
Wants).

They do not want to put the Wants relationship in their service file
because they do not know the target they are in or if they are being run
as a standalone service via the command line. Starting a synchronization
target outside of the target it is meant for could have impacts on power
on or off operations.

To ensure the synchronization targets are started in the appropriate
situations, add them to the main power on and off targets directly.

Testing:
- Built image, verified basic boot and power off
- Ran HW CI tests and verified they passed

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

show more ...

synch targets: ensure wants relationship

Synchronization targets (i.e. targets that do not have services
underneath them) require "Wants" relationships to ensure they are
started and utilized. In mo

synch targets: ensure wants relationship

Synchronization targets (i.e. targets that do not have services
underneath them) require "Wants" relationships to ensure they are
started and utilized. In most cases a service using them as a
synchronization target will ensure they are started but to be sure,
this should be explicitly defined within the targets themselves.

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

show more ...

soft-off: ensure pldm soft svc stopped on hard poweroff

There is a new pldmSoftPowerOff.service that will be utilized on PLDM
based systems to notify the host to power off. Need to ensure this
servi

soft-off: ensure pldm soft svc stopped on hard poweroff

There is a new pldmSoftPowerOff.service that will be utilized on PLDM
based systems to notify the host to power off. Need to ensure this
service is stopped if the user requests a hard chassis power off.

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

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 ...

boot-block: don't power on if blocking err present

If the user has enabled the setting to block the boot if an error with a
CALLOUT is logged and such an error is logged, ensure the chassis-poweron

boot-block: don't power on if blocking err present

If the user has enabled the setting to block the boot if an error with a
CALLOUT is logged and such an error is logged, ensure the chassis-poweron
target does not complete.

See the following design for more details:
https://github.com/openbmc/docs/blob/master/designs/fail-boot-on-hw-error.md

Tested:
With the following series of commits:
https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-logging/+/32155/
- Verified that obmc-chassis-poweron@0.target did not complete when an
unresolved error was present.
- Verified that target did complete once the log was resolved

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

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 ...

diag-mode: create new diagnostic mode target

This target will be used when the host is collecting diagnostic data. In
most cases this data is to help debug a failure of some sort in the host
subsyst

diag-mode: create new diagnostic mode target

This target will be used when the host is collecting diagnostic data. In
most cases this data is to help debug a failure of some sort in the host
subsystem.

phosphor-state-manager will track the entry and exit of this target
within its xyz.openbmc_project.State.Host D-Bus object. It will
correlate to "xyz.openbmc_project.State.Host.HostState.DiagnosticMode"

This target will be driven by other software components which are
communicating with the host and coordinating the diagnostics so the
target itself will have minimal services within it.

The CurrentHostState property within xyz.openbmc_project.State.Host will
be mapped to the InTest state within Redfish when this target is
running. The expectation is the target is only active when the host is
actively collecting diagnostic data.

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

show more ...

warm-reboot: add in new targets

These targets will be used to implement the new Host transitions defined
in the following design doc:
https://github.com/openbmc/docs/blob/master/designs/state-manage

warm-reboot: add in new targets

These targets will be used to implement the new Host transitions defined
in the following design doc:
https://github.com/openbmc/docs/blob/master/designs/state-management-and-external-interfaces.md

They provide the capability to reboot the host without cycling power to
the chassis. This makes reboots faster and can enable other features
where chassis power is needed to preserve certain aspects of the host
state.

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

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 ...