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
We would need to stabilize newer pam_mount (but it's blocked because no version in the tree is even compiling :S)
Isn't /proc/self/mounts better?
(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
Any news here? Thanks!
(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?
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
And, then, I think there is no blockers against this change :|
*** Bug 484816 has been marked as a duplicate of this bug. ***
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?
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
(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."
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?
nilfs-utils issue is not resolved, but at least cleared and could be easily fixed.
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?
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 :)
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?
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?
[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.
(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?
(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
(In reply to Rick Farina (Zero_Chaos) from comment #20) My comment was about https://bugzilla.linux-nfs.org/show_bug.cgi?id=188
(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)
(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.
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 ~ $
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.
Bug 497278 should be added to the blockers.
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?
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
(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'?
(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.
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?
(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.
(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.
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
# 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.
- 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.
Seamless on VM via chroot Main host failed up to now via chroot under installcd as jospezial recommends
It looks like we are moving toward completely ignoring /etc/mtab and using /proc.
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.
