[systemd-devel] [RFC] the chopping block

[Lennart Poettering]

On Sat, 13.02.16 00:10, Christian Seiler (christian at iwakd.de) wrote:

> On 02/12/2016 10:34 PM, Lennart Poettering wrote:
> > On Fri, 12.02.16 17:49, Simon McVittie (simon.mcvittie at collabora.co.uk) wrote:
> > 
> >> On 11/02/16 17:06, Lennart Poettering wrote:
> >>> 5) Here's the controversial one I think: support for booting up
> >>>    without /var. We have kludges at quite a few places because we
> >>>    cannot access /var early during boot.
> >>
> >> I don't think /var is really the same thing as /usr: for a start, it has
> >> to be read/write, whereas /usr and / can be read-only for at least the
> >> early stages of boot.
> >>
> >> On stateless systems with a read-only / and /etc, requiring /var to be
> >> mounted from the initramfs would mean that the mechanism for setting up
> >> /var (NFS or tmpfs or whatever) would have to move into the
> >> initramfs.
> > 
> > Since initrds tend to cover root-on-nfs, root-on-iscsi and so on
> > anyway, that sounds like no change in behaviour really..
> 
> Well, kind-of. The root-on-nfs and root-on-iscsi are dumbed-down
> versions of what's possible once a system is booted.

Well, to my understanding dracut and stuff makes pretty much all
storage tech that is available during the normal system also available
in the initrd, with the same software, to make sure testing stays
managable. It waits for the root disk and for /usr with the same
machanics (i.e. the systemd logic of .device units, fsck services and
.mount units). And quite frankly that's really how an initrd should
work really: use the same logic and the same software as the host
would...

I think you are extrapolating from limitations of one specific initrd
implementation, no? It sounds really as if that implementation should
be fixed though... 

> PS: Btw. if you do run journald already in initramfs (which I
> think is a good thing to have), then it still needs to have
> code to flush /run/log/journal to /var/log/journal. So in that
> case you don't actually gain anything.

The journal isn't really the issue, as /var is generally read-only
initially anyway. 

(and yeah, I am pretty sure initrd should run systemd – which implies
running journald too – for reasons described above: you want to keep
the differences minimal)

My maingoal here is really about having read-access to things, and
being able to schedule stuff based on configuration and existance of
things, even if that stuff cannot be written to yet. If /var is
mounted this late it makes things a lot more complex.

Lennart

-- 
Lennart Poettering, Red Hat