recovery-chooser-trigger.service: Survive the switch root

[valentindavid]

snap-bootstrap recovery-chooser-trigger is only expected to use
/run so it can safely survive the switch root.

When using stateful re-execution of systemd, this will keep the same
service started from initramfs and continue into the main boot.

Because we need to pull it into initrd-switch-root.target, we also
need to remove default dependencies so that we do not indirectly pull
sysinit.target or local-fs.target into
initrd-switch-root.target.

Note, we should probably add a signal handler in snap-bootstrap recovery-chooser-trigger to be notified when initrd-root-fs.target
is reached to chdir into /sysroot so that we do not drag the old
initramfs in memory until it is stopped. This is because systemd will
lazily umount the old root.

[anonymouse64]

thanks for this change, can you clarify what the order of release should be? if this change was included in the initramfs today without the signal handling you mention are there any side-effects? do we need to do that signal handling before this change can be released/included in kernel snaps?

[anonymouse64]

as clarified on mattermost since this does not need the signal handling added to the recovery chooser trigger (it would merely be an improvement), this looks good to me

[valentindavid]

thanks for this change, can you clarify what the order of release should be? if this change was included in the initramfs today without the signal handling you mention are there any side-effects? do we need to do that signal handling before this change can be released/included in kernel snaps?

The side effect is only memory not released right away. We do not need change in snap-bootstrap. It is just nice.

Also note that this PR will only do something after #58. So maybe we can wait for #58 to be merged. Potentially without #58, we could have 2 runs of recovery-chooser-trigger in the same time. Though it should not be a problem, but I have not tested that.

[anonymouse64]

Also note that this PR will only do something after #58. So maybe we can wait for #58 to be merged. Potentially without #58, we could have 2 runs of recovery-chooser-trigger in the same time. Though it should not be a problem, but I have not tested that.

In general I think it's actually better to do the inverse - land as much as possible changes that do nothing, then turn them on with a simple PR at the end. So I think we should land this before the stateful re-exec in #58 (and also I think we should do the stateful re-exec change as part of #59 too unless there's a compelling reason not to)

[valentindavid]

In general I think it's actually better to do the inverse - land as much as possible changes that do nothing, then turn them on with a simple PR at the end. So I think we should land this before the stateful re-exec in #58 (and also I think we should do the stateful re-exec change as part of #59 too unless there's a compelling reason not to)

OK, I have tested manually the change and it does not seem to break. Do I need to trigger snapd spread tests for just that change?

[alfonsosanchezbeato]

LGTM!

[alfonsosanchezbeato]

FTR, this is how plymouth changes its working folder after the switch root:
https://gitlab.freedesktop.org/plymouth/plymouth/-/blob/main/src/main.c#L649
(maybe not needed for recovery-chooser-trigger, but leaving here as reference, just in case)