/etc/mtab

[Bernie Innocenti]

What's preventing us from symlinking /etc/mtab to /proc/mounts and get
rid of confusing situations when mtab gets out of sync with the kernel?

I tried running my system for a few months this way. The only
regressions I'm seeing are:

1) the Gnome Disk Mounter panel applet seems to get confused. After a
loopback mount gets unmounted, there's still an icon to remount the
device. (the loopback device is correctly cleaned up at umount time).

2) on boot, the system tries to remount /sys even though it's already
mounted, thus spitting this harmless error:

Remounting root filesystem in read-write mode: [  OK  ]
mount: according to mtab, /dev/sda1 is already mounted on /
Mounting local filesystems:  mount: sysfs already mounted or /sys busy
mount: according to mtab, /sys is already mounted on /sys [FAILED]
Enabling /etc/fstab swaps: [  OK  ]

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs       - http://sugarlabs.org/

[Till Maas]

On Wed, Dec 22, 2010 at 10:38:21PM -0500, Bernie Innocenti wrote:
>  What's preventing us from symlinking /etc/mtab to /proc/mounts
> and get
>  rid of confusing situations when mtab gets out of sync with the kernel? 
It is not possible to set the files ystem in /proc/mounts as it is
possible with /etc/mtab. This breaks the usage of mount helper tools
like mount.crypt from pam_mount that allows to mount and umount
encrypted partitions using mount. To get umount.crypt called when umount
of an encrypted file system is run, crypt needs to be written in
the file system column in /etc/mtab.

Regards
Till

[Lennart Poettering]

On Wed, 22.12.10 22:38, Bernie Innocenti (bernie(a)codewiz.org) wrote:

>  What's preventing us from symlinking /etc/mtab to /proc/mounts
> and get
>  rid of confusing situations when mtab gets out of sync with the
>  kernel? 
Some of the mount options that /bin/mount uses currently are seen by
userspace only and cannot be attached to the mount point in-kernel. The
effect of that is that if you symlink /etc/mtab to /proc/mounts these
options get silently dropped after mount, and while they might have
effect at mount time, afterwards (i.e. umount time) they will have zero
effect. An example of such an option is "user" and "users".

It is definitely planned to get rid of /etc/mtab, but before that
happens the kernel must either learn to store userspace mount options
along kernel mount options for each mount point in some way (Miklos
Szeredi has been working on this IIRC), or /bin/mount must learn to
store these options somewhere in userspace (for example /dev/.mount or
so), and then augment its output with these options. (Karel Zak has been
thinking about adding this).

Sooner or laer we will definitely make /etc/mtab a symlink, which should
take us one definite step nearer to supporting r/o root by default. 

In fact, in systemd we already warn during boot if /etc/mtab is not a
symlink, and we do not longer clear that file on bootup, all to put a
tiny bit of pressure on the folks involved to fix this properly once and
for all, in the F15 timeframe...

>  I tried running my system for a few months this way. The only
>  regressions I'm seeing are:
>  
>  1) the Gnome Disk Mounter panel applet seems to get confused. After a
>  loopback mount gets unmounted, there's still an icon to remount the
>  device. (the loopback device is correctly cleaned up at umount time). 
Loop devices use userspace-only mount options too, afair.

>  2) on boot, the system tries to remount /sys even though it's
> already
>  mounted, thus spitting this harmless error:
>  
>  Remounting root filesystem in read-write mode: [  OK  ]
>  mount: according to mtab, /dev/sda1 is already mounted on /
>  Mounting local filesystems:  mount: sysfs already mounted or /sys busy
>  mount: according to mtab, /sys is already mounted on /sys [FAILED]
>  Enabling /etc/fstab swaps: [  OK  ] 
This problem is gone on F15/Rawhide anyway, since systemd mounts this dir.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Ian Kent]

On Thu, 2010-12-23 at 12:12 +0100, Lennart Poettering wrote:
>  On Wed, 22.12.10 22:38, Bernie Innocenti (bernie(a)codewiz.org) wrote:
>  
>  > What's preventing us from symlinking /etc/mtab to /proc/mounts and get
>  > rid of confusing situations when mtab gets out of sync with the
>  > kernel?
>  
>  Some of the mount options that /bin/mount uses currently are seen by
>  userspace only and cannot be attached to the mount point in-kernel. The
>  effect of that is that if you symlink /etc/mtab to /proc/mounts these
>  options get silently dropped after mount, and while they might have
>  effect at mount time, afterwards (i.e. umount time) they will have zero
>  effect. An example of such an option is "user" and "users".
>  
>  It is definitely planned to get rid of /etc/mtab, but before that
>  happens the kernel must either learn to store userspace mount options
>  along kernel mount options for each mount point in some way (Miklos
>  Szeredi has been working on this IIRC), or /bin/mount must learn to
>  store these options somewhere in userspace (for example /dev/.mount or
>  so), and then augment its output with these options. (Karel Zak has been
>  thinking about adding this). 
And lets not forget the need for a pseudo mount option that can be used
by the user space tools to ignore certain mounts, such as autofs mounts.

>  
>  Sooner or laer we will definitely make /etc/mtab a symlink, which should
>  take us one definite step nearer to supporting r/o root by default. 
>  
>  In fact, in systemd we already warn during boot if /etc/mtab is not a
>  symlink, and we do not longer clear that file on bootup, all to put a
>  tiny bit of pressure on the folks involved to fix this properly once and
>  for all, in the F15 timeframe...
>  
>  > I tried running my system for a few months this way. The only
>  > regressions I'm seeing are:
>  > 
>  > 1) the Gnome Disk Mounter panel applet seems to get confused. After a
>  > loopback mount gets unmounted, there's still an icon to remount the
>  > device. (the loopback device is correctly cleaned up at umount time).
>  
>  Loop devices use userspace-only mount options too, afair.
>  
>  > 2) on boot, the system tries to remount /sys even though it's already
>  > mounted, thus spitting this harmless error:
>  > 
>  > Remounting root filesystem in read-write mode: [  OK  ]
>  > mount: according to mtab, /dev/sda1 is already mounted on /
>  > Mounting local filesystems:  mount: sysfs already mounted or /sys busy
>  > mount: according to mtab, /sys is already mounted on /sys [FAILED]
>  > Enabling /etc/fstab swaps: [  OK  ]
>  
>  This problem is gone on F15/Rawhide anyway, since systemd mounts this dir.
>  
>  Lennart
>  
>  -- 
>  Lennart Poettering - Red Hat, Inc.

[Karel Zak]

On Thu, Dec 23, 2010 at 12:12:12PM +0100, Lennart Poettering wrote:
>  On Wed, 22.12.10 22:38, Bernie Innocenti (bernie(a)codewiz.org) wrote:
>  It is definitely planned to get rid of /etc/mtab, but before that
>  happens the kernel must either learn to store userspace mount options
>  along kernel mount options for each mount point in some way (Miklos
>  Szeredi has been working on this IIRC), or /bin/mount must learn to 
 It seems kernel will never be so promiscuous to care about arbitrary
 userspace mount options. 
 
 Miklos wants to store fsuid (uid of the task doing the mount(2) syscall)
 to VFS and make it accessible in /proc/self/{mounts,mountinfo}. This 
 will resolve our problem with user= mount option.

 The others userspace (FS specific) mount options have to be managed
 by filesystem drives, we shouldn't expect any generic solution by
 VFS. The other solution is to store these options somewhere in
 userspace (see below).

>  store these options somewhere in userspace (for example /dev/.mount
> or
>  so), and then augment its output with these options. (Karel Zak has been
>  thinking about adding this). 
 Yes, mount(8) in F15 will store arbitrary userspace mount options to
 /dev/.mount/utab if a regular /etc/mtab does not exist. This feature
 is implemented in incoming libmount.
 
 In F16 the whole mount(8) (and some mount.<type> helpers) will be
 based on libmount. Now we use the library for findmnt(8) only.

>  Sooner or laer we will definitely make /etc/mtab a symlink, which
> should
>  take us one definite step nearer to supporting r/o root by default. 
>  
>  In fact, in systemd we already warn during boot if /etc/mtab is not a
>  symlink, and we do not longer clear that file on bootup, all to put a
>  tiny bit of pressure on the folks involved to fix this properly once and
>  for all, in the F15 timeframe... 
 Thanks :-)

>  > 1) the Gnome Disk Mounter panel applet seems to get confused.
> After a
>  > loopback mount gets unmounted, there's still an icon to remount the
>  > device. (the loopback device is correctly cleaned up at umount time).
>  
>  Loop devices use userspace-only mount options too, afair. 
 mount(8) in F15 will use auto-clear flag for loopdevs, the loop=
 option will be unnecessary in mtab.

    Karel

-- 
 Karel Zak  <kzak(a)redhat.com&gt;
 http://karelzak.blogspot.com