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

[Tom Gundersen]

On Tue, Sep 10, 2013 at 6:47 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> On Fri, 23.08.13 15:51, Colin Walters (walters at verbum.org) wrote:
>
>>
>> First, thanks for working on this, most of these patches look sane to
>> me.
>>
>> On Fri, 2013-08-23 at 15:09 +0800, Tom Gundersen wrote:
>>
>> > +        if (path_equal(m->where, "/") ||
>> > +            path_equal(m->where, "/usr"))
>> > +                return false;
>>
>> 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).

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.

Cheers,

Tom