[systemd-devel] systemd shutdown vs ostree

[Lennart Poettering]

On Thu, 12.09.13 23:31, Colin Guthrie (gmane at colin.guthr.ie) wrote:

> 
> 'Twas brillig, and Lennart Poettering at 12/09/13 21:51 did gyre and gimble:
> > On Thu, 12.09.13 21:27, Colin Guthrie (gmane at colin.guthr.ie) wrote:
> > 
> >>> So, as mentioned in the other thread, /usr should probably be on some
> >>> "OS resource blacklist" or so, and not attempted to be shutdown.
> >>>
> >>> But unmounting /var during shutdown should actually work. The only thing
> >>> that currently stops this from working cleanly is that journald is
> >>> configured to stay around until the last moment, but currently has not
> >>> interface to tell it to move its logging back to /run from /var. When we
> >>> have that then the /var issue should go away for you, no?
> >>
> >> It would be quite nice to have an easy way for a compliant initrd to say
> >> it can and will handle /var unmounting (perhaps by dropping a
> >> var.mount.d/ snippet in the /run/systemd/system/ folder at boot?). 
> > 
> > Yeah, such a drop-in should just work. Just add "DefaultDependencies=no"
> > in there, and maybe instead "Before=local-fs.target", and you should be set.
> 
> Nice, I'm sure dracut could implement that then.
> 
> >> This will allow us to get persistent logs in which the initrd can
> >> report it's progress until the last possible moment. This might help
> >> debugging any problems in this particular link of the shutdown chain.
> > 
> > I think the really late shutdown logs should more liekly end up in some
> > EFI var and then flushed out on next boot or so...
> 
> Nice plan. How would be able to "trust" that data tho'. Would it have to
> be signed in some way? Or could it be marked somehow as unreliable data?
> I'm not sure it really *matters* that much from a trust perspective as
> it's use would likely be 99% debugging, but all the same it would be
> nice if it were trustable.

Trust?  I mean, if you managed to upload data into EFI vars you are so
privileged you can fuck with us anyway, so not sure what you mean....

Lennart

-- 
Lennart Poettering - Red Hat, Inc.