[OE-core] [OE-Core][PATCH] systemd: Default to non-stateless images

[Alex Kiernan]

On Mon, May 6, 2019 at 12:18 PM Jonas Bonn <jonas at norrbonn.se> wrote:
>
> Hi Alex,
>
> On 06/05/2019 11:36, Alex Kiernan wrote:
> > On Mon, May 6, 2019 at 5:54 AM Jonas Bonn <jonas at norrbonn.se> wrote:
> >>
> >> Hi Alex,
> >>
> >> The below is fine and looks good.  The one thing that bothers me about
> >> this is that "stateless" isn't really a property of the "distro", rather
> >> it's a property of the image/machine.
> >
> > I agree it should be part of image, I'll respin it.
> >
> >>   I suspect, in the same sense that
> >> we have readonly-rootfs, that we should probably have image features
> >> "stateless-rootfs" (no /etc, no /var) and "volatile-rootfs" (no /var).
> >>
> >
> > That makes sense to me
> >
> >> Furthermore, if you want to boot with 'ro' on the command-line, I really
> >> think you need to build your image with the "readonly-rootfs" feature
> >> set.  The default should be writable+persistent /etc as that's the
> >> configuration used 99% of the time (currently).  "readonly-rootfs" does
> >> a bit more than just creating machine-id but it's all relevant to the
> >> 'ro' case where /etc isn't writable.
> >>
> >
> > I think there's (at least) two use cases for ro boot:
> >
> > - systems which boot ro and stay that way
> > - systems which transition to rw during systemd-remount-fs
> >
> > I'm in the second case as I have no initramfs and need the filesystem
> > readonly until it's fscked/remounted rw.
>
> I'd argue that you are abusing systemd for this because systemd
> explicity requires /etc to be writable.  The fact that it works on a
> read-only /etc is both incidental and fragile.
>

Not sure... systemd is explicit in its machinery for some parts of
this ro->rw transition (e.g. systemd-machine-id-commit.service),
though it's admittedly silent on what the state of the rest of /etc
is.

> That said, I understand why you want to do this.  Have you considered
> putting the fsck in a "systemd generator" that doesn't return until fsck
> finishes?  Generators are kind of like units that run before systemd
> starts... or, at least, they can be (ab)used in this way.  Systemd won't
> start until all the generators are finished (the idea being that the
> generators may be responsible for creating units dynamically).
>

If systemd comes along and breaks it yes... or I'll teach
ostree-prepare-root how to do it, but right now the sequencing is all
there in systemd.


--
Alex Kiernan