obmcutil: fix shellcheck issues

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

update documentation on clearing of *-on files

See previous commits in this series for the reasoning behind this.

TLDR: Clearing them on the power off paths caused complexity with other
paths like

update documentation on clearing of *-on files

See previous commits in this series for the reasoning behind this.

TLDR: Clearing them on the power off paths caused complexity with other
paths like BMC resets with the host up and warm reboots.

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

show more ...

remove host@%d-on from config options

As noted in earlier reviews, this is not a configurable option.
Multiple service files throughout OpenBMC have hard coded this path
within themselves.

Make thi

remove host@%d-on from config options

As noted in earlier reviews, this is not a configurable option.
Multiple service files throughout OpenBMC have hard coded this path
within themselves.

Make this a hard coded variable instead within meson so that it can be
utilized across multiple phosphor-state-manager applications.

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

show more ...

clear temp reset file on chassis on

See the following for more information on this file:
https://github.com/openbmc/phosphor-state-manager#bmc-reset-with-host-andor-chassis-on

Currently this file i

clear temp reset file on chassis on

See the following for more information on this file:
https://github.com/openbmc/phosphor-state-manager#bmc-reset-with-host-andor-chassis-on

Currently this file is cleared via the op-wait-power-off service in the
power down path. Upon further review, it's best to just clear this once
it has served its purpose which is to allow the chassis object to
get back into the On state after the BMC has been reset when the
chassis power is still on.

The simplification allows us to avoid the different corner cases of warm
reboots and memory preserving reboots and how those interact with BMC
reboots with the chassis power on.

Once this change is in, we can remove the deletion of this file from
the op-wait-power-off service.

Tested:
- Verified on a witherspoon that a reboot of the BMC worked as expected
and the /run/openbmc/ files were deleted correctly
- Ran HW CI regression against witherspoon and verified no failures

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

show more ...

clear temp reset file on host running

See the following for more information on this file:
https://github.com/openbmc/phosphor-state-manager#bmc-reset-with-host-andor-chassis-on

Currently this file

clear temp reset file on host running

See the following for more information on this file:
https://github.com/openbmc/phosphor-state-manager#bmc-reset-with-host-andor-chassis-on

Currently this file is cleared via two service files in the power
down path. Upon further review, it's best to just clear this once
it has served its purpose which is to allow the host object to
get back into the Running state after the BMC has been reset when the
host is still running.

The simplification allows us to avoid the different corner cases of warm
reboots and memory preserving reboots and how those interact with BMC
reboots with the host up.

Once this change is in, we can remove the deletion of this file from
the service files (op-stop-instructions and op-wait-power-off).

Tested:
- This was tested in combination with the next commit. See it for
testing details.

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

show more ...

reduce scheduled host transition logging

The BMC time can change periodically due to NTP or on some systems, via
periodic host commands. Change the logs that are impacted by this
time change to debu

reduce scheduled host transition logging

The BMC time can change periodically due to NTP or on some systems, via
periodic host commands. Change the logs that are impacted by this
time change to debug so the journal is not filled up with them.

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

show more ...

power-restore: one-time support

The one_time PowerRestorePolicy property was introduced so system owners
could utilize the feature for one time type scenarios without rewriting
all of the logic on t

power-restore: one-time support

The one_time PowerRestorePolicy property was introduced so system owners
could utilize the feature for one time type scenarios without rewriting
all of the logic on their own.

IBM wishes to utilize the one_time power restore policy to cause an
automatic power on after an in-band firmware update.

The one_time setting is defined by default within meta-phosphor here:
https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/40948

Testing:
- Set one time and verify it's the one used and then reset to default
busctl set-property xyz.openbmc_project.Settings /xyz/openbmc_project/control/host0/power_restore_policy/one_time xyz.openbmc_project.Control.Power.RestorePolicy PowerRestorePolicy s xyz.openbmc_project.Control.Power.RestorePolicy.Policy.AlwaysOff

busctl get-property xyz.openbmc_project.Settings /xyz/openbmc_project/control/host0/power_restore_policy/one_time xyz.openbmc_project.Control.Power.RestorePolicy PowerRestorePolicy
s "xyz.openbmc_project.Control.Power.RestorePolicy.Policy.AlwaysOff"

phosphor-discover-system-state

Feb 25 19:44:11 witherspoon phosphor-discover-system-state[495]: One time set, use it and reset to default

busctl get-property xyz.openbmc_project.Settings /xyz/openbmc_project/control/host0/power_restore_policy/one_time xyz.openbmc_project.Control.Power.RestorePolicy PowerRestorePolicy
s "xyz.openbmc_project.Control.Power.RestorePolicy.Policy.None"

- Verify when one time setting is at default it is ignored
busctl get-property xyz.openbmc_project.Settings /xyz/openbmc_project/control/host0/power_restore_policy/one_time xyz.openbmc_project.Control.Power.RestorePolicy PowerRestorePolicy
s "xyz.openbmc_project.Control.Power.RestorePolicy.Policy.None"

phosphor-discover-system-state

Feb 25 19:47:08 witherspoon phosphor-discover-system-state[498]: One time not set, check user setting of power policy
Feb 25 19:47:08 witherspoon phosphor-discover-system-state[498]: Host power is off, processing power policy

- Verify the one time power on path
busctl get-property xyz.openbmc_project.Settings /xyz/openbmc_project/control/host0/power_restore_policy/one_time xyz.openbmc_project.Control.Power.RestorePolicy PowerRestorePolicy
s "xyz.openbmc_project.Control.Power.RestorePolicy.Policy.AlwaysOn"

phosphor-discover-system-state

Feb 25 20:14:15 witherspoon phosphor-discover-system-state[504]: One time set, use it and reset to default
Feb 25 20:14:15 witherspoon phosphor-discover-system-state[504]: Host power is off, processing power policy
Feb 25 20:14:15 witherspoon phosphor-discover-system-state[504]: power_policy=ALWAYS_POWER_ON, powering host on

busctl get-property xyz.openbmc_project.Settings /xyz/openbmc_project/control/host0/power_restore_policy/one_time xyz.openbmc_project.Control.Power.RestorePolicy PowerRestorePolicy
s "xyz.openbmc_project.Control.Power.RestorePolicy.Policy.None"

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

show more ...

hypervisor: reset requested host state on power off

The hypervisor only supports a one-shot Standby->Running transition
request. To make things more user friendly, reset the requested
transition on

hypervisor: reset requested host state on power off

The hypervisor only supports a one-shot Standby->Running transition
request. To make things more user friendly, reset the requested
transition on server power off's since there's no reason to keep around
the previous requests.

Tested:
- Built image with all related changes and verified hypervisor state
correctly tracked with BootProgress and that requesting an On
transition successfully made it to the hypervisor.

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

show more ...

hypervisor: monitor boot progress

The BootProgress property will be tracked to set the hypervisor state as
appropriate

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

hypervisor: monitor boot progress

The BootProgress property will be tracked to set the hypervisor state as
appropriate

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

show more ...

hypervisor: state management support

Some systems have a hypervisor firmware stack which they wish to track
and change the state of. This new state management object will provide
this function if a

hypervisor: state management support

Some systems have a hypervisor firmware stack which they wish to track
and change the state of. This new state management object will provide
this function if a user selects to bring it into their system.

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

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

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

Put state change values into the journal message

On the journal entries that mention host or chassis state changes, put
the actual state in the journal message instead of keeping it in the
metadata.

Put state change values into the journal message

On the journal entries that mention host or chassis state changes, put
the actual state in the journal message instead of keeping it in the
metadata. This lets someone debugging state changes avoid having to use
the verbose journal to find the state values.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Ib102d700b692070fae87e525d7b7ccba75d0227b

show more ...

autoreboot: add one-time support to obmcutil

Since this is a one-time property and is cleared on a host stop, no need
to provide an option to set it back to true in obmcutil.

Tested:
root@witherspo

autoreboot: add one-time support to obmcutil

Since this is a one-time property and is cleared on a host stop, no need
to provide an option to set it back to true in obmcutil.

Tested:
root@witherspoon:/lib/systemd/system# obmcutil hostrebootoffonetime
root@witherspoon:/lib/systemd/system# busctl get-property xyz.openbmc_project.Settings /xyz/openbmc_project/control/host0/auto_reboot/one_time xyz.openbmc_project.Control.Boot.RebootPolicy AutoReboot
b false

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

show more ...

autoreboot: add one-time property to logic

Utilize the new one-time AutoReboot property when determining if
AutoReboot is enabled on the system.

Tested:
Verified one-time setting was utilized if fa

autoreboot: add one-time property to logic

Utilize the new one-time AutoReboot property when determining if
AutoReboot is enabled on the system.

Tested:
Verified one-time setting was utilized if false, otherwise the non
one-time setting was used.

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

show more ...

autoreboot: one-time object support

The new one_time D-Bus object is utilized for setting RebootPolicy for a
single boot. phosphor-state-manager will always look at this object
first for reboot poli

autoreboot: one-time object support

The new one_time D-Bus object is utilized for setting RebootPolicy for a
single boot. phosphor-state-manager will always look at this object
first for reboot policy, if it is the default of true, then
phosphor-state-manager will then look at the persistent user setting
under the non one_time object path.

See the following commit for more info:
https://github.com/openbmc/meta-phosphor/commit/7d29e7a2c135e91b222c57c66bb7ca61aae6398e

Tested:
Via some debug statements, confirmed that Path variables are both
updated with correct settings object.

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

show more ...

autoreboot: clear one time properties on chassis off

The one-time properties are only meant to last for one boot so ensure
they are reset when the chassis is powered off.

Tested:
root@witherspoon:/

autoreboot: clear one time properties on chassis off

The one-time properties are only meant to last for one boot so ensure
they are reset when the chassis is powered off.

Tested:
root@witherspoon:/lib/systemd/system# busctl set-property xyz.openbmc_project.Settings /xyz/openbmc_project/control/host0/auto_reboot/one_time xyz.openbmc_project.Control.Boot.RebootPolicy AutoReboot b false
root@witherspoon:/lib/systemd/system# busctl get-property xyz.openbmc_project.Settings /xyz/openbmc_project/control/host0/auto_reboot/one_time xyz.openbmc_project.Control.Boot.RebootPolicy AutoReboot
b false
root@witherspoon:/lib/systemd/system# systemctl start obmc-chassis-poweroff\@0.target
root@witherspoon:/lib/systemd/system# busctl get-property xyz.openbmc_project.Settings /xyz/openbmc_project/control/host0/auto_reboot/one_time xyz.openbmc_project.Control.Boot.RebootPolicy AutoReboot
b true

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

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

bmc_state_manager: Add HardReboot support to BMC

Add HardReboot support to BMC for ForceRestart
Below is patch supporting this change.
https://gerrit.openbmc-project.xyz/#/c/openbmc/bmcweb/+/33695

bmc_state_manager: Add HardReboot support to BMC

Add HardReboot support to BMC for ForceRestart
Below is patch supporting this change.
https://gerrit.openbmc-project.xyz/#/c/openbmc/bmcweb/+/33695

Tested:
1. On Redfish can use ForceRestart to HardReboot the BMC.
2. Verified using Redfish url.
3. Verified using busctl call.
Command:
busctl call xyz.openbmc_project.State.BMC
/xyz/openbmc_project/state/bmc0 org.freedesktop.DBus.Properties
Set ssv xyz.openbmc_project.State.BMC RequestedBMCTransition s
xyz.openbmc_project.State.BMC.Transition.HardReboot

Results: BMC hard rebooted successfully.

Signed-off-by: Jayaprakash Mutyala <mutyalax.jayaprakash@intel.com>
Change-Id: Ie646ba84c066b43638be5efcd94622a0af8c33b8

show more ...

option to disable warm reboots

The concept of warm reboot (reboot the host without removing chassis
power) was added a while back as a part of clarifying support for
the Redfish ComputerSystem.Reset

option to disable warm reboots

The concept of warm reboot (reboot the host without removing chassis
power) was added a while back as a part of clarifying support for
the Redfish ComputerSystem.Reset Action. It has since been found that
some IBM hardware, including Witherspoon, does not support warm reboots.
The issue is intermittent and depends on the reboot being requested
while the host is in the middle of some i2c transactions. If a warm
reboot occurs during this window, then on the subsequent boot the i2c
hardware will be in a bad state and the host firmware is unable to
recover it.

Given this issue, it has been requested that BMC software go back to
doing cold reboots (cycling power to the chassis during any reboot
request) on this hardware.

The solution in this commit is to provide a new config flag. By default
phosphor-state-manager continues to use the warm reboot targets when
requested but system owners via a .bbappend can turn off this flag
and go back to using the default cold reboot target.

This change was initially proposed within bmcweb, with this commit:
https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/33656

The general consensus was that this change should occur in the back
end of the code and bmcweb should not be involved.

Tested:
- Verified that by default warm reboot targets were still used
- Verified that when overriding compile option in a .bbappend that
the cold reboot target was used

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

show more ...

obmcutil: fix optional param regression

When adding support for "showlog", it regressed the support for the
optional parameters. That new option required all of the command line
parameters be passed

obmcutil: fix optional param regression

When adding support for "showlog", it regressed the support for the
optional parameters. That new option required all of the command line
parameters be passed on to handle_cmd().

handle_cmd() does not handle optional parameters though. Add some logic
to shift the optional parameters out before calling handle_cmd().

Tested:
Verified -v and -w/--wait now work as expected

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

show more ...

clang-format: update to latest from docs repo

This is from openbmc/docs/style/cpp/.clang-format

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

clang-format: update to latest from docs repo

This is from openbmc/docs/style/cpp/.clang-format

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

show more ...