[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