[systemd-devel] [PATCH 6/7] mount: filesystems mounted in the initrd should not conflict with umount.target in the real root

Lennart Poettering lennart at poettering.net
Wed Sep 11 07:31:25 PDT 2013


On Tue, 10.09.13 19:54, Tom Gundersen (teg at jklm.no) wrote:

> >> But it annoys me that we're propagating this hardcoding in the new code
> >> too.  How about we make systemd inspect /proc/self/mountinfo *very*
> >> early on at boot when it starts, and ensure skip unmounting these, under
> >> the assumption they'll be taken care of either in the initrd, or by the
> >> final kill spree?
> >
> > I'd actually prefer having an explicit blacklist for this, so that we
> > don't have to trust the initrd too much that...
> 
> Not sure if I get in what sense you mean we need to trust the initrd.
> What I thought we'd do was to simply notice what filesystems were
> already mounted when systemd first started in the real root (so
> whatever caused them to be mounted in the initrd is not important).

What gives me the headache there is that initrds are so varied right
now. It just gives me headaches leaving it to the numerous initrds
implementations to decide what the file systems with "OS resources"
are. I'd much rather define clearly that /etc, / and /usr are OS
resources in the systemd context, rather then leave that definition to
the inirds/dsitro packagers... This is too close to the core of the OS
to leave this undefined and varying between the distributions I'd say...

> If you meant we'd need to trust the initrd to umount them correctly at
> shutdown, I guess we could keep doing the umount loop in the real root
> also for the "premounted" filesystems (and at least remount them ro),
> but not complain too much if we can't umount them, as the failure is
> sort of expected.
> 
> I'm not too keen on a blacklist. It would work for the simple case of
> course, but I have seen lots of fancy/complicated stuff being mounted
> in the initrd for people doing live media/install discs, which I
> really don't think we can/should cover by using an explicit list.

Well, everything that this list would declare is that /, /etc, /usr (and
maybe very few others) are the bits that systemd requires to be
mounted when the host's systemd is first invoked. Where it is mounted
from, and in which order would be up to the distros, but I'd really
would like to make it clear that these three dirs *must* be valid when
the host systemd initializes.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.


More information about the systemd-devel mailing list