[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:55:20 PDT 2013


On Wed, 11.09.13 10:46, Colin Walters (walters at verbum.org) wrote:

> 
> > 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.
> 
> That makes total sense!  

BTW, I started putting this together:

http://www.freedesktop.org/wiki/Software/systemd/FileHierarchy/

Which is supposed to document the actual requirements systemd
makes. i.e. that subset of the FHS that systemd actually cares
about. Suggestions welcome.

> But my concern is more about *unmounting*.  So
> let's say that an initramfs uses some special filesystem for /etc that
> causes it be a mountpoint; for example, it's backed by a special NVRAM
> device.

Well, but /etc would be one of those which would be listed in that "OS
resource dir list"... 

> I think systemd should just assume that the initramfs will take care of
> unmounting it, and not attempt to unmount it "gracefully" by default,
> i.e. save it until the final kill spree.  And more generally for all
> filesystems that were mounted by the initramfs.

Note that killing spree is done before we jump back into the
initramfs...

So there's three steps:

1. normal unmounting using mount units
2. killing spree unmounting of left-overs in a tight loop based on /proc/self/mountinfo
3. initrd unmounting of remaining OS resource dirs

Where 3 is optional, and done only on initrds which implement this.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.


More information about the systemd-devel mailing list