Ideas for completing WIP "add unit to switch back to initrd at shutdown" etc

[Alan Jenkins]

On 12/06/18 14:25, Ray Strode wrote:
> Hi,
>
> It sounds like you've put a lot of thought into this.  Are you
> interested in working on it?

I think so, yes.

* reminder to self:  plymouth-switch-root-shutdown also absolutely needs 
to be ordered after dracut-shutdown.service (which populates 
/run/initramfs)...  I guess this has to become part of the 
plymouth<->initrd interface.

>
> On Tue, Jun 12, 2018 at 6:50 AM, Alan Jenkins
> <alan.christopher.jenkins at gmail.com> wrote:
>> I see the WIP commits which included "add unit to switch back to initrd at
>> shutdown" etc have been reverted for now.
> [...]
>
>> Of course I'd be interested to hear why the WIPs
>> were reverted.  Did the reexec approach come to seem more promising? Or was
>> the WIP just taking too long to finish?
> Those were never meant to go to master. They were just a quick draft
> branch that snuck onto master when I was pushing some unrelated fixes.
> It was incomplete, untested, and probably doesn't work. This problem,
> in general, is on my back-burner radar and I haven't had time to work
> on it (RHEL has been taking up a lot my time recently)
>
>> * I was unhappy with the WIP originally, because I didn't want my system to
>> be left with a frozen graphic (kept up by plymouth-drm-escrow).  I would
>> want the option to see the text console messages, like I can with the escape
>> key in current plymouth.  But I withdraw this objection: I think the design
>> still allows this feature.  It seems straightforward, particularly if
>> drm-escrow doesn't bother to implement switching *back* to graphics mode :).
> So I'm actually unhappy with plymouth-drm-escrow because I don't think
> it's actually necessary. systemd has a feature we can use instead:
> `sd_pid_notify_with_fds` and `FDSTORE=1` so I think i'd rather if the
> branch was reworked to leverage that, so we don't have to deal with
> the lifecycle management of a child process etc.
>
> The rest of what you said makes sense to me, and it seems like you've
> thought of more corner cases than I did.  If you want to pick it up
> where I left, let me know.  Sounds good to me.
>
> --Ray

I might be abusing your terminology.  And I'm slightly vague about 
"drm-escrow", but I think I've been assuming I can have plymouthd exec() 
into "drm-escrow".  Then there is no child process :-) and there's a 
natural way to detect if exec() of drm-escrow fails e.g. because the 
initrd was rebuilt without plymouth.  I guess I should check my 
assumption by working on this part first.

I think the fdstore wouldn't help with the design.  (I'm familiar with 
it from how logind uses the fdstore for drm devices).

Thanks for reviewing this. The points you made seem good to bear in mind.
Alan