Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 477498 - sys-apps/baselayout: /etc/mtab should be a symlink to /proc/mounts with linux >= 2.6.26
Summary: sys-apps/baselayout: /etc/mtab should be a symlink to /proc/mounts with linux...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] baselayout (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: William Hubbs
URL:
Whiteboard:
Keywords:
: 484816 (view as bug list)
Depends on: 461388 487920 487962 497278
Blocks: 434090 477240 477254
  Show dependency tree
 
Reported: 2013-07-20 14:04 UTC by Pacho Ramos
Modified: 2016-08-26 17:45 UTC (History)
14 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pacho Ramos gentoo-dev 2013-07-20 14:04:57 UTC
I hit this problem when moving to systemd and noticed it wanted me to create that link. Then, after talking with mgorny, he pointed me to past bugs, but that showed me that the migration was done already in distributions like Fedora and Debian, and all is discussed and explained at:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=494001

Thanks a lot

Reproducible: Always
Comment 1 Pacho Ramos gentoo-dev 2013-07-20 14:06:04 UTC
We would need to stabilize newer pam_mount (but it's blocked because no version in the tree is even compiling :S)
Comment 2 Fabio Erculiani (RETIRED) gentoo-dev 2013-07-20 14:25:19 UTC
Isn't /proc/self/mounts better?
Comment 3 Pacho Ramos gentoo-dev 2013-07-20 14:44:36 UTC
(In reply to Fabio Erculiani from comment #2)
> Isn't /proc/self/mounts better?

yeah, it's now that one ;)

Thanks for pointing it out
Comment 4 Pacho Ramos gentoo-dev 2013-08-28 09:51:42 UTC
Any news here? Thanks!
Comment 5 William Hubbs gentoo-dev 2013-09-03 17:40:32 UTC
(In reply to Pacho Ramos from comment #4)
> Any news here? Thanks!

Baselayout is stable on multiple architectures where pam_mount doesn't have keywords, so if we did this it would have to be conditional on which architectures do not support pam_mount, or we need pam_mount to be keyworded everywhere baselayout is keyworded for Linux.

Thoughts?
Comment 6 Pacho Ramos gentoo-dev 2013-09-03 17:53:15 UTC
pam_mount is not needed by the link, my previous comment was about it looking to not work ok in the past when that link was used, but newer versions fixing the problem. If you don't have pam_mount you won't suffer the problem at all
Comment 7 Pacho Ramos gentoo-dev 2013-09-21 13:49:41 UTC
And, then, I think there is no blockers against this change :|
Comment 8 William Hubbs gentoo-dev 2013-10-12 16:06:37 UTC
*** Bug 484816 has been marked as a duplicate of this bug. ***
Comment 9 Peter Volkov (RETIRED) gentoo-dev 2013-10-12 16:56:40 UTC
Most of distributions either did this switch or will switch in the nearest future, so we also need to do make this change. That said, Pacho, may be 'short' discussion in -dev?
Comment 10 Peter Volkov (RETIRED) gentoo-dev 2013-10-12 17:16:28 UTC
And I'm not sure that this is blocker, but yet, nilfs-utils are unable to work with /proc/mtab being symlink. I've pinged upstream on this, but we'll see how it goes there: http://marc.info/?l=linux-nilfs&m=138159795211469&w=2
Comment 11 Pacho Ramos gentoo-dev 2013-10-12 18:35:07 UTC
(In reply to Peter Volkov from comment #9)
> Most of distributions either did this switch or will switch in the nearest
> future, so we also need to do make this change. That said, Pacho, may be
> 'short' discussion in -dev?

Could it be done by other one? People will identify me as a "systemd/gnome guy" and would likely start the classic systemd flame :| Even if debian bug report explains why this is good even for non-systemd systems (like debian itself ;))

"With linux >= 2.6.26, /proc/mounts contains all of the information in 
/etc/mtab, plus more.  The mount system call can now pass all of the mount 
options to the kernel, so no information is missing in /proc/mounts.  This 
has obviously useful benefits such as read-only root, and the state in 
/etc/mtab never gets out of sync with reality (there are a number of open 
bugs against mount where this occurs).

Additionally, with the addition of per-process namespaces with CLONE_NEWNS to 
clone(2), each process has its own set of mounts, and as such a system-wide 
/etc/mtab is useless: it's only valid in one of the potentially many 
namespaces and can quickly get into a horrible mess.  At this point, 
/etc/mtab *must* be a symlink to avoid breakage.  Note that /proc/mounts is 
now a symlink to /proc/self/mounts for this reason: each process has
potentially different mounts."
Comment 12 William Hubbs gentoo-dev 2013-10-13 18:40:28 UTC
I could revbump baselayout and set it up to do this when the stages are built.

What about on live systems though? Right now the systemd ebuild recommends doing this manually, and OpenRC doesn't touch /etc/mtab if it is a symlink.

Would it be appropriate to send out a newsitem and direct people to do this manually?
Comment 13 Peter Volkov (RETIRED) gentoo-dev 2013-10-13 19:53:03 UTC
nilfs-utils issue is not resolved, but at least cleared and could be easily fixed.
Comment 14 Ulenrich 2013-10-17 17:54:31 UTC
Pacho Ramos
>Could it be done by other one? People will identify me as a "systemd/gnome guy"

Obviously, there is a bug in the Gentoo users community:
Conspiracy theory aggressivly claimed by a bunch of users wrecking the nerves of Gentoo developers. Should I open a bug targeting the community?
Comment 15 Pacho Ramos gentoo-dev 2013-10-17 18:15:44 UTC
Well, better to leave it for now, I was thinking in some private mails I hit weeks ago from some users that looked to be really angry... I expect they will finally see my intention is not to kill openrc or similar :)
Comment 16 Thomas Deutschmann gentoo-dev Security 2013-11-24 02:39:27 UTC
BTW:

'man mount' says

  When the proc filesystem is mounted (say at /proc), the files /etc/mtab
  and /proc/mounts have very similar contents. The former has somewhat
  more information, such as the mount options used, but is not necessarily
  up-to-date (cf. the -n option below). It is possible to replace /etc/mtab
  by a symbolic link to /proc/mounts, and especially when you have very
  large numbers of mounts things will be much faster with that symlink, but
  some information is lost that way, and in particular using the "user"
  option will fail.

Is that invalid/not a problem?
Comment 17 nobody 2013-12-20 18:49:56 UTC
Fix nfs-utils prior to do that, i just find this bug because libmount was force enable on nfs-utils stable system to help fixing that bug.

Some options aren't shown in /proc/self/mounts ; and this cause issues: user cannot unmount nfs share, remounting nfs fail...
Look at https://bugzilla.linux-nfs.org/show_bug.cgi?id=188

Debian bug doesn't just change /etc/mtab to a symlink, debian has look for problems and fix them.
It seems they store in /run/utab the infos so when /etc/mtab is symlink they get it from /run/utab instead. And they patch and fix their tools to seek infos in /run/utab.

This is not what this bug report is doing : 
- There's no bugs reference in this bug except for systemd problems.
- Also none from non systemd users : simply because they have no problem as they use mtab file and not a symlink.

Contrary to debian this bug is just forcing mtab symlink to make systemd happy. And this will broke non systemd user system as a result.

Pacho Ramos, you are just pushing this to remove systemd bug, without taking care of what this change will do on others. It might not be intentionally done to break their system, but that will be the result of your action.
And you wonder why people sent you angry email?
Comment 18 Rick Farina (Zero_Chaos) gentoo-dev 2013-12-20 19:08:08 UTC
[ebuild   R    ] net-fs/nfs-utils-1.2.9  USE="caps ipv6 libmount nfsidmap nfsv4 tcpd uuid -kerberos -nfsdcld -nfsv41 (-selinux)" 0 kB

I am using openrc with no systemd anywhere in sight.  My /etc/mtab is a symlink to /proc/mounts/self and it's bee working great for me.  I can mount, I can unmount, no issues.  As a fact, when running two instances of catalyst with all it's crazy mounts, this is the only way my system doesn't have mount errors.
Comment 19 Alexander Tsoy 2013-12-20 19:46:15 UTC
(In reply to Stéphane Pagnon from comment #17)
> Some options aren't shown in /proc/self/mounts ; and this cause issues: user
> cannot unmount nfs share, remounting nfs fail...
> Look at https://bugzilla.linux-nfs.org/show_bug.cgi?id=188

How this bug is related to /proc/self/mounts?
Comment 20 Rick Farina (Zero_Chaos) gentoo-dev 2013-12-20 20:49:15 UTC
(In reply to Alexander Tsoy from comment #19)
> (In reply to Stéphane Pagnon from comment #17)
> > Some options aren't shown in /proc/self/mounts ; and this cause issues: user
> > cannot unmount nfs share, remounting nfs fail...
> > Look at https://bugzilla.linux-nfs.org/show_bug.cgi?id=188
> 
> How this bug is related to /proc/self/mounts?

zero@ozzie ~ % ls -al /proc/mounts
lrwxrwxrwx 1 root wheel 11 Dec 20 15:50 /proc/mounts -> self/mounts
Comment 21 Alexander Tsoy 2013-12-20 20:59:39 UTC
(In reply to Rick Farina (Zero_Chaos) from comment #20)
My comment was about https://bugzilla.linux-nfs.org/show_bug.cgi?id=188
Comment 22 nobody 2013-12-23 02:10:47 UTC
(In reply to Alexander Tsoy from comment #21)
> (In reply to Rick Farina (Zero_Chaos) from comment #20)
> My comment was about https://bugzilla.linux-nfs.org/show_bug.cgi?id=188

If mtab isn't a file nfs bug as it cannot record the info it need and miss some information from the mount.
You get it ? mtab not a file == mtab a symlink == mtab not a file?

And because /proc/self/mounts doesn't record ALL options given to mount a FS. You are loosing information.

Look where "user=krinn" goes ?
$ mount /mnt/faramir/public/
$ cat /proc/self/mounts | grep public
faramir:/public/ /mnt/faramir/public nfs4 rw,nosuid,nodev,noexec,relatime,vers=4.0,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.0.4,local_lock=none,addr=192.168.0.6 0 0
$ mount | grep public
faramir:/public on /mnt/faramir/public type nfs4 (rw,noexec,nosuid,nodev,addr=192.168.0.6,clientaddr=192.168.0.4,user=krinn)
Comment 23 Alexander Tsoy 2013-12-23 17:36:17 UTC
(In reply to Stéphane Pagnon from comment #22)
But how about /run/mount/utab? AFAIK it is used by libmount to store userspace mount options.
Comment 24 Alexander Tsoy 2013-12-23 18:04:17 UTC
Here some tests. /etc/mtab is a symlink to /proc/self/mounts, nfs-utils is built with USE=libmount. Looks like everything works fine:

puleglot@rpi-two ~ $ mount /mnt/test

No "user=" option in /etc/mtab:

puleglot@rpi-two ~ $ grep /mnt/test /etc/mtab 
192.168.1.1:/mnt/test /mnt/test nfs4 rw,nosuid,nodev,noexec,noatime,vers=4.0,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.67,local_lock=none,addr=192.168.1.1 0 0

but it is present in /run/mount/utab:

puleglot@rpi-two ~ $ grep /mnt/test /run/mount/utab
SRC=192.168.1.1:/mnt/test TARGET=/mnt/test ROOT=/ ATTRS=vers=4,addr=192.168.1.1,clientaddr=192.168.1.67 OPTS=user=puleglot

and `mount` command shows it:

puleglot@rpi-two ~ $ mount | grep /mnt/test
192.168.1.1:/mnt/test on /mnt/test type nfs4 (rw,nosuid,nodev,noexec,noatime,vers=4.0,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.67,local_lock=none,addr=192.168.1.1,user=puleglot)

unmounting also works fine:

puleglot@rpi-two ~ $ umount /mnt/test 
puleglot@rpi-two ~ $ mount | grep /mnt/test
puleglot@rpi-two ~ $
Comment 25 nobody 2013-12-24 03:30:37 UTC
At first it didn't work, but with libmount it works, /run/mount/utab is filled with proper values. nfs-utils works like before.
Thanks for the info A. Tsoy.
Comment 26 Alexander Tsoy 2014-02-18 22:23:38 UTC
Bug 497278 should be added to the blockers.
Comment 27 Horea Christian 2014-06-24 06:15:39 UTC
I just had this issue (all manner of automounting was messed up in GNOME, apparently because /etc/mtab was a file and not symlink). Nobody knew how to help me fix it for quite a few weeks, until someone finally pointed me this way. 

Terribly distressing issue. Why isn't this symlink created automatically? Would I have needed a particular flag for this to happen?
Comment 28 William Hubbs gentoo-dev 2014-08-13 18:14:55 UTC
This has been added to the stages for Linux in commit d79832c.
This will be included in baselayout-2.3.

A discussion came up on the mailing list in the past about whether we
should automate it on live systems, and the feeling was that we
shouldn't, so you should be able to safely run these commands as root:

rm /etc/mtab
ln -snf /proc/self/mounts /etc/mtab
Comment 29 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-08-13 20:06:24 UTC
(In reply to William Hubbs from comment #28)
> A discussion came up on the mailing list in the past about whether we
> should automate it on live systems, and the feeling was that we
> shouldn't, so you should be able to safely run these commands as root:
> 
> rm /etc/mtab
> ln -snf /proc/self/mounts /etc/mtab

If you do remove /etc/mtab first, why not plain 'ln -s'?
Comment 30 William Hubbs gentoo-dev 2014-08-14 06:36:36 UTC
(In reply to Michał Górny from comment #29)
> (In reply to William Hubbs from comment #28)
> > A discussion came up on the mailing list in the past about whether we
> > should automate it on live systems, and the feeling was that we
> > shouldn't, so you should be able to safely run these commands as root:
> > 
> > rm /etc/mtab
> > ln -snf /proc/self/mounts /etc/mtab
> 
> If you do remove /etc/mtab first, why not plain 'ln -s'?

You could do that, or you could just drop the rm command.

This is one of those situations where more than one way to complete the task exists.
Comment 31 Markus Rathgeb 2014-08-14 08:14:33 UTC
Do not know if this is a must, but would it be better to use relative paths?

ln -snf ../proc/self/mounts /etc/mtab

IMHO this is seen more often.

What with Gentoo Prefix?
Comment 32 William Hubbs gentoo-dev 2014-08-14 15:53:51 UTC
(In reply to Markus Rathgeb from comment #31)
> Do not know if this is a must, but would it be better to use relative paths?

I'm not sure, but I don't see how it would be since /proc is always /proc.

> ln -snf ../proc/self/mounts /etc/mtab
> 
> IMHO this is seen more often.
> 
> What with Gentoo Prefix?

A prefix doesn't have mounts of its own that are different from the host. I'm not even sure that a prefix would have its own version of mtab.
Comment 33 Richard Yao gentoo-dev 2014-08-15 18:48:58 UTC
(In reply to Pacho Ramos from comment #0)
> I hit this problem when moving to systemd and noticed it wanted me to create
> that link. Then, after talking with mgorny, he pointed me to past bugs, but
> that showed me that the migration was done already in distributions like
> Fedora and Debian, and all is discussed and explained at:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=494001

This is not always desirable. It is useful in containers, but those containers likely have their own separate root filesytems and people can change it manually there. Those that want to use systemd can install a symlink themselves. If systemd is using /etc/mtab itself, it should stop.
Comment 34 jospezial 2015-04-28 20:04:55 UTC
I noticed today when my system booted up I saw:

* Remounting filesystems ...
 [ ok ]
 * Updating /etc/mtab ...
 * The support for updating /etc/mtab as a file is
 * deprecated and will be removed in the future.
 * Please run the following command as root on your system.
 * ln -snf /proc/self/mounts /etc/mtab
 [ ok ]


found that in /var/log/rc.log

Which package did this?
Was it openrc-0.14.ebuild ?
I find no info about mtab in /sys-apps/openrc/ChangeLog or openrc-0.14.ebuild
Comment 35 Thomas Deutschmann gentoo-dev Security 2015-04-28 20:37:26 UTC
# bzcat /usr/share/doc/openrc-0.14/ChangeLog.bz2 | head -n 17
commit a6391f44ee6c68d674ae8425983467b971710d5d
Author: William Hubbs <w.d.hubbs@gmail.com>
Commit: William Hubbs <w.d.hubbs@gmail.com>

    mtab: move toward requiring /etc/mtab to be a symbolic link

    This changes the mtab service in the following way:

    - If /etc/mtab is a symbolic link, success is returned.
    - If /etc is not writable, we warn that we could not update /etc/mtab
      and return success.
    - If /etc/mtab does not exist, we create a symbolic link from
      /etc/mtab to /proc/self/mounts.
    - Otherwise, we warn that updating /etc/mtab as a file is
      deprecated and continue to update it after outputting instructions to
      the user for how to move it to a symbolic link.
Comment 36 jospezial 2015-04-28 22:25:15 UTC
- If /etc/mtab does not exist, we create a symbolic link from
      /etc/mtab to /proc/self/mounts.

For those who want to test this point:
I tried deleting the file and reboot.
Problem is, on shutdown the regular file is recreated. I think when remounting / readonly.
I had to do the deletion from a live-cd.
Now the symlink was created on boot and seems to work.
Comment 37 CaptainBlood 2015-07-29 21:14:40 UTC
Seamless on VM via chroot
Main host failed up to now via chroot under installcd as jospezial recommends
Comment 38 William Hubbs gentoo-dev 2015-11-28 15:54:55 UTC
It looks like we are moving toward completely ignoring /etc/mtab and using /proc.
Comment 39 William Hubbs gentoo-dev 2016-08-26 17:45:03 UTC
This has been fixed for a while. In OpenRC, the mtab service has a
strong preference for /etc/mtab being a symbolic link and as shown above
this is fixed in baselayout-2.3.