fix(systemd-255): handle systemd-pcrphase -> systemd-pcrextend

[ferringb]

In systemd 255 systemd-pcrphase was renamed to systemd-pcrextend; there was no other change to it, just the rename.

Unit scripts are still named systemd-pcrphase, just the underlying binary got renamed. Thus adapt the module
to check for either binary.

Changes

Adds awareness of systemd-pcrextend binary allowing systemd-pcrphase module to work with systemd-255.

Checklist

• I have tested it locally
• I have reviewed and updated any documentation if relevant
• [] I am providing new code and test(s) for it
  // copy/rename of existing code, and existing lacks tests...

Fixes #2583

[ferringb]

Pardon the noise; my testing of my previous patch was lackluster; this was verified properly.

[ferringb]

@dtardon what you asked for is addressed, and this is still horked in mainline. Is there anything blocking this being merged?

[dtardon]

@dtardon what you asked for is addressed, and this is still horked in mainline. Is there anything blocking this being merged?

That doesn't depend on myself... I'm just a contributor; I don't have the rights to merge PRs.

[ferringb]

@dtardon pardon, my bad.

@haraldh or @johannbg , both of you are listed as code owners. Any chance you can address this?

[johannbg]

@dtardon pardon, my bad.

@haraldh or @johannbg , both of you are listed as code owners. Any chance you can address this?

Interesting there are quite few dragons there in systemd v255 release for downstream enterprise distro's and downstream that support multiple init systems anyway there is no such thing as "just a rename" when upstream changes a executable name.

The scope of this changes requires
A new module ( systemd-pcrextend )
Existing module being renamed and turned into a meta module to provide a clean upgrade/migration path for downstream.

A simple optional inclusion will not be merged to address this upstream systemd change.
It is more than it's made to appear to be as is always the case when upstream "rename" things...

[dtardon]

The scope of this changes requires A new module ( systemd-pcrextend ) Existing module being renamed and turned into a meta module to provide a clean upgrade/migration path for downstream.

Sorry, but what?! Meta modules are useful for alternative impls. of a concept, but this isn't that. It's a simple rename of an internal binary. The service name remains the same, which is what really matters, because it's user-visible. There will be just one of the binaries on the system at any point, hence a simple optional inclusion already provides all the migration path that's needed. Anything else is an overkill. (Even if a system--and consequently an initrd generated on it--ended up containing both binaries somehow, it wouldn't matter anyway. The old systemd-pcrphase-initrd.service calls systemd-pcrphase, while the v255 one calls systemd-pcrextend, hence there'd still be no problem/confusion.)

A simple optional inclusion will not be merged to address this upstream systemd change. It is more than it's made to appear to be as is always the case when upstream "rename" things...

No, it isn't. This is an internal binary, not supposed to be called by users. Hence this rename is transparent to users. It only affects dracut and possibly other initrd/image generators that need to poke at package internals.

[lnykryn]

I agree with @dtardon here. For reference: systemd/systemd@32295fa

[LaszloGombos]

Relevant section of the dracut wiki - https://github.com/dracutdevs/dracut/wiki/Dracut-development#compatibility

The compatibility promise is primary towards end users and not towards Linux distributions packaging dracut. Distribution packaging will need changes time-to-time between dracut releases (e.g. as files gets added and removed).

[johannbg]

Relevant section of the dracut wiki - https://github.com/dracutdevs/dracut/wiki/Dracut-development#compatibility

The compatibility promise is primary towards end users and not towards Linux distributions packaging dracut. Distribution packaging will need changes time-to-time between dracut releases (e.g. as files gets added and removed).

Looking at that wikipage it's quite evident that I need to start restricting who can create and edit wiki pages.

[johannbg]

I agree with @dtardon here. For reference: systemd/systemd@32295fa

Modules are based upon the upstream configuration options so correct dependency chain can be kept downstream ( which is what this module systemd-pcrphase was based upon ) If those configuration options change upstream ( which most certainly did with this change ) those changes will be reflected here as well.

So to be perfectly clear on the matter this wont get merged in any other form than in a new module ( systemd-pcrextend ) and the existing module being renamed and turned into a meta module to provide a clean upgrade/migration path for downstream so this PR can be update to reflect that or it can be closed.

[ferringb]

I agree with @dtardon here. For reference: systemd/systemd@32295fa

Modules are based upon the upstream configuration options so correct dependency chain can be kept downstream ( which is what this module systemd-pcrphase was based upon ) If those configuration options change upstream ( which most certainly did with this change ) those changes will be reflected here as well.

So to be perfectly clear on the matter this wont get merged in any other form than in a new module ( systemd-pcrextend ) and the existing module being renamed and turned into a meta module to provide a clean upgrade/migration path for downstream so this PR can be update to reflect that or it can be closed.

Closing this out. Feel free to cut your own fix.

[dtardon]

I agree with @dtardon here. For reference: systemd/systemd@32295fa

Modules are based upon the upstream configuration options so correct dependency chain can be kept downstream ( which is what this module systemd-pcrphase was based upon ) If those configuration options change upstream ( which most certainly did with this change ) those changes will be reflected here as well.

So to be perfectly clear on the matter this wont get merged in any other form than in a new module ( systemd-pcrextend ) and the existing module being renamed and turned into a meta module to provide a clean upgrade/migration path for downstream so this PR can be update to reflect that or it can be closed.

Have you even read what I had written?

[LaszloGombos]

I understand that this PR is closed now, but IMHO Linux distributions will end up taking this PR, so perhaps we should try to address the shellcheck issue with it even if it is not landed here.

'shfmt -s' returned error 1 finding the following formatting issues:

----------
--- modules.d/01systemd-pcrphase/module-setup.sh.orig
+++ modules.d/01systemd-pcrphase/module-setup.sh
@@ -7,9 +7,9 @@
 
     # If the binary(s) requirements are not fulfilled the module can't be installed.
     # systemd-255 renamed the binary, check for old and new location.
-    if ! require_binaries "$systemdutildir"/systemd-pcrphase && \
-       ! require_binaries "$systemdutildir"/systemd-pcrextend; then
-       return 1
+    if ! require_binaries "$systemdutildir"/systemd-pcrphase \
+        && ! require_binaries "$systemdutildir"/systemd-pcrextend; then
+        return 1