systemd: no installation in templated targets

Upstream yocto introduced a change via e510222 (systemd-systemctl:
fix instance template WantedBy symlink construction).

This fixes a bug that we in Op

systemd: no installation in templated targets

Upstream yocto introduced a change via e510222 (systemd-systemctl:
fix instance template WantedBy symlink construction).

This fixes a bug that we in OpenBMC had been taking advantage of in that
we were able to document our templated target dependencies without it
actually doing anything. The real installation of services within
targets occurs in our bitbake recipes due to the complexity of chassis
and host instances on a per machine basis.

Leave the dependency information in the service files but comment them
out. It's useful to be able to look at a service and understand which
targets it's going to be installed into by the bitbake recipes.

In some cases, we had hard coded the target instance, which does install
the service correctly, but only in that one target. All services should
be installed via the bitbake recipe to ensure the service is properly
installed in all instances of the target (or service). Once the bump for
this commit goes into openbmc/openbmc, I will ensure the recipe is
updated to install all services correctly.

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

show more ...

ensure hostboot volatile not cleared on warm reboots

A while back, the obmc-vpnor-enable-clearvolatile@.service was added to
the obmc-chassis-poweron@.target. This was done to ensure the volatile
da

ensure hostboot volatile not cleared on warm reboots

A while back, the obmc-vpnor-enable-clearvolatile@.service was added to
the obmc-chassis-poweron@.target. This was done to ensure the volatile
data was cleared on any chassis power on to handle situations where the
user is using debug tools like istep or cronus to boot the system after
the chassis power was turned on. Prior to that, the clear was done only
when obmc-host-start@.target was started.

Adding this service to the obmc-chassis-poweron@target had an unintended
consequence though. The chassis power on target is called during a warm
reboot. The assumption was that all services were already running so it
was a "warm" reboot because none of those service were re-run. The
obmc-vpnor-enable-clearvolatile@.service however is a onetime service
that did not remain after exit. This means this service was run during
this warm reboot which breaks the design point of not clearing the host
volatile data on a warm reboot.

This commit now makes this service continue after it has run and only
stops it when a chassis power off is issued. This ensures the host
volatile data is only ever cleared after a system has its chassis
powered off.

Tested:
- Verified that a warm reboot now results in the service not running
- Verified that a normal host reboot (chassis power cycle) still results
in the service running as expected

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

show more ...

vpnor: Move clearvolatile services to vpnor

The clearvolatile services were originally in the ubi layout, but
the functionality is purely for vpnor, not tied to a filesystem
layout. Move them to the

vpnor: Move clearvolatile services to vpnor

The clearvolatile services were originally in the ubi layout, but
the functionality is purely for vpnor, not tied to a filesystem
layout. Move them to the vpnor layer where non-UBI layouts that use
virtual pnor such as eMMC have this functionality.

Tested: Verified on witherspoon that the renamed services were
included in the image and ran during a power on.

Change-Id: I6e9e9e4f5a8a7690a46872ee2fdc0fc96e621482
Signed-off-by: Adriana Kobylak <anoo@us.ibm.com>

show more ...