Searched hist:"8 c90f319d579357e671c7ebbf8b845f680bb1aa2" (Results 1 – 3 of 3) sorted by relevance
/openbmc/phosphor-power/services/ |
H A D | phosphor-regulators-monitor-enable.service | 8c90f319d579357e671c7ebbf8b845f680bb1aa2 Tue May 09 14:04:15 CDT 2023 Andrew Geissler <geissonator@yahoo.com> 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. Once the bump for this commit goes into openbmc/openbmc, I will ensure the recipe is updated to install all services correctly.
Change-Id: Ie8ec6b5fabe196bac669187ce50ee3b13262c98f Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
|
H A D | phosphor-regulators-config.service | 8c90f319d579357e671c7ebbf8b845f680bb1aa2 Tue May 09 14:04:15 CDT 2023 Andrew Geissler <geissonator@yahoo.com> 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. Once the bump for this commit goes into openbmc/openbmc, I will ensure the recipe is updated to install all services correctly.
Change-Id: Ie8ec6b5fabe196bac669187ce50ee3b13262c98f Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
|
H A D | phosphor-regulators-monitor-disable.service | 8c90f319d579357e671c7ebbf8b845f680bb1aa2 Tue May 09 14:04:15 CDT 2023 Andrew Geissler <geissonator@yahoo.com> 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. Once the bump for this commit goes into openbmc/openbmc, I will ensure the recipe is updated to install all services correctly.
Change-Id: Ie8ec6b5fabe196bac669187ce50ee3b13262c98f Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
|