Move preload and firejail setup to oneshot script

[nephros]

Workarounds/fixes for #521

Instead of setting up files in %post, do it in a script and launch that
through the oneshot feature

[nephros]

Note: this PR is currently untested, i.e. installation of a package with these changes has not yet been attempted.

Update: I have done a couple of de-installations and re-installations, and to me it seems to work as expected.

[b100dian]

I like this solution, even though it is sailfishos specific (or because it is?), If @Olf0 does not have anything against I think we should merge and see if there are any more reports.

[Olf0]

If @Olf0 does not have anything against I think we should merge and see if there are any more reports.

Thanks; I had little time the past two months, but will now take a look at it soon™.

[Olf0]

@nephros, can you please check my understanding denoted in commit ce0d96c, specifically if I expanded "the link" correctly.

I plan to thoroughly review the shell code proper soon™.

[nephros]

@nephros, can you please check my understanding denoted in commit ce0d96c, specifically if I expanded "the link" correctly.

I plan to thoroughly review the shell code proper soon™.

All fine! :) (the original comment was straight from the oneshot manual, but this version is better.

Now, what could happen is if this run of the oneshot "fails" for whatever reason, PM will not be functional (pretty much as described in #521).
The situation should resolve itself after a reboot (provided the oneshot is executed then).

[nephros]

I just did an update of my C2 to 5.0.0.73(EA), having installed a build of PM called patchmanager-3.2.12+obs.20251217121522.165.g81845d3-1.17.1.bso.aarch64 which includes a variant of this PR, and I am still affected by #521.

/etc/ld.so.preload and /etc/firejail/whitelist-common.local are unchanged (from default) after the update, so it seems the oneshot script either never got executed, or failed changing the files.

I will have to investigate...

[nephros]

I just did an update of my C2 to 5.0.0.73(EA), having installed a build of PM called patchmanager-3.2.12+obs.20251217121522.165.g81845d3-1.17.1.bso.aarch64 which includes a variant of this PR, and I am still affected by #521.

/etc/ld.so.preload and /etc/firejail/whitelist-common.local are unchanged (from default) after the update, so it seems the oneshot script either never got executed, or failed changing the files.

I will have to investigate...

1. possible reason:

The preload macro is executed in the "at package install" section of the rpm %post. Therefore it is not executed when one updates from a PM package which used the old method.

Perhaps the fix for that is to call it also in the "at package update" case (but perhaps without the --now switch).

Changed in 629d735.

[EDIT:] Tested that, and it works fine.

2. possible reason:

If I understand correctly, the script is run exactly once (if a symlink exists in /etc/oneshot.d). If the run is successful, the symlink is removed.
So if the timeline is

• SFOS version X installed
• PM installed -> oneshot script either executed at install, or at the next reboot.
• After oneshot is run, symlink is removed
• PM running OK
• SFOS version updated from X->Y -> preload and whitelist files replaced by default ones
• boot during/after update -> no oneshot script is run, default files remain in place
• --> Bug [Bug] PM operational, but enabled patches show no effect - after system update #521

For this issue, we could either "always fail" (exit 1) in the script.
Or come up with something that is only done on system update. Some insights from the ancient #39 may help here.

[nephros]

Or come up with something that is only done on system update. Some insights from the ancient #39 may help here.

I wonder:

Make a service like this:

[Unit]
...
After=system-update-pre.target
After=sailfish-upgrade-ui.service
Before=system-update.target

[Service]
Type=oneshot
RemainAfterExit=True

ExecStart=/bin/true
ExecStop=setup-patchmanager-foo

This should then run setup-patchmanager-foo once at the end of a system update, right?

If that is true, let setup-patchmanager-foo be add-oneshot patchmanager-setup-preload.sh and we're good?

[nephros]

Soo, what is the chance that 8d4e507 actually "bricks" devices by causing a failure during OS updates? Or regular boot?

Do we risk it?