On Thu, Jul 21, 2011 at 12:45 PM, Karel Zak <kzak(a)redhat.com> wrote:
> really that is exactly what you want to do on your system. If our
> mount command will still attempt to write to /etc/mtab once its a real
> file again, maybe things will work for you as expected.
No. systemd is not compatible with /etc/mtab
To be clear, you are saying that systemd won't be updating /etc/mtab
like the mount command tries to do?
If so, I believe a sufficiently motivated admin would be able to
figure out a way to manually update /etc/mtab from /proc/mounts if
they wanted to see systemd mounted items in their site specific mtab
they are trying to maintain. I don't think its impossible, I've
seen(created) crazier site specific admin hacks to keep backwards
compatibility on an as needed basis.
Just for completely I've done some more historical searches and I'm
seeing this argument between mtab and /proc/*/mounts going all the
way back to 2000. And in all of the historic discussion I've seen
relying on ./proc/*/mount has been the recommendation due to it being
a canonical representation of what the mount points actually are at
any given point in time.
Ten+ years of trying to live with two slightly different ways of
accounting for mountpoints, each with their own limitations is more
than enough time. While the bind mount situation we have now is
somewhat unfortunate in that we didn't catch it in time to be
proactive about it in F15, the fact that we've been living with this
divergence for ten years speaks volumes about the necessity to bite
the bullet and cut over to the /proc/*/mount information in a release
and triage accordingly as the breakage reports come it.
Do you have a complete listing somewhere of the info thekernel does
not encode into /proc/mounts that mount has traditionally encodes into
/etc/mtab that existing tools might be making use of? I'm pretty sure
based on everything I've read its not just bind mount info, but also
perhaps user or group info concerning who has permission to mount and
umount? Moving foward such a list would probably help mitigate
frustration and give admins a starting point to adjusting their site