See bug #214877 for some context If /etc/ is read-only, by /etc/mtab is bind-mounted to a tmpfs, then mount still fails to update mtab because it can't create the lock file in /etc/ There's no sane way to work around this with e.g. /etc/rwtab, because we would need to allow all of /etc/ to be writable since the lock file name uses the processes pid. Seems like the most obvious solution is to maintain these locks in /var/lock. Trivial patch attached.
Created attachment 140838 [details] util-linux-mtab-move-lock-files.patch
Well, how will be the mount work with your patch if the /var will be different filesystem? "mount /var" ? I think all mount stuff must be at root filesystem only.
... and it's not so easy. There is more programs that writes to /etc/mtab. You have to change all of these utils (/sbin/[u]mount.[cifs|gfs|nfs|*], am-utils, ...).
(In reply to comment #2) > Well, how will be the mount work with your patch if the /var will be different > filesystem? "mount /var" ? Hah. Point :) In this case, though, /etc/mtab will be on a separate filesystem too. We just mount it with -n, though > I think all mount stuff must be at root filesystem only. Except, we now support a read-only root filesystem (In reply to comment #3) > ... and it's not so easy. There is more programs that writes to /etc/mtab. You > have to change all of these utils (/sbin/[u]mount.[cifs|gfs|nfs|*], am-utils, > ...). Yep.
We also need to figure out how to make sure all the utilities which care about mtab~ locking are updated in lock-step with each other. ie, it would be extremely bad if some of the utilities were using /etc/mtab~ and others were using /var/lock/mtab~. Presumably this *can* be done with RPM. Not being an RPM guru, I'm probably not the best person to actually encode those changes into the spec files. Jeff
FYI -- /var/lock is part of the root filesystem as provided by the "filesystem" RPM. So really we just need to fix all the [u]mount utilities to move the lock file into /var/lock and get the updates out in a synchronized manner. Jeff
FYI -- looks like the following need updating for moving the mtab lock file into /var/lock: /bin/[u]mount /sbin/[u]mount.{cifs,gfs2,ncp,ncpfs,nfs,nfs4} /usr/lib/ncp{map,mount,login,umount} /usr/lib/libamu.so /usr/libexec/hal-* puts a lock file in /media (ugh); however, given that /media is going to need to be in /etc/rwtab anyway for hal storage bits to work at all, it's something we don't need to fix today. I didn't check anything in Fedora Extras, but I suspect we may need updates to hfs, ntfs and maybe a couple other things. In all it's not too terrible. Jeff
What's the current state of StatelessLinux?
This is pretty much a show stopper for StatelessLinux. If mtab doesn't get updated all kinds of bad things happen. mount -a results in things being mounted twice possibly overlaying old mounts. If root gets mounted again it will be mounted ro over all the bind mounts, effectively hiding them.
I think we're better off throwing a union mount on top of /etc. It resolves the mtab problem and a few others. I've been reasonably happy with the fuse based unionfs -- the only "big" problem is it wants to update mtab when creating the union mount, which obviously doesn't work (in fact, it hangs due to implementation details of FUSE). The FUSE guys were supposed to add a -n option to their mount program to suppress mtab updates, but I haven't checked on it for a while (I'm currently on an extended leave). Jeff
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
*** Bug 359621 has been marked as a duplicate of this bug. ***
It seems that we are not getting anything like union mounts in Fedora any time soon. Could priority on this be stepped up?
Moving locks to /var is definitely the clean solution, however, for what its worth, a viable work around is to make /etc/mtab a symbolic link to /proc/mounts and always use the -n option to mount and unmount. This is definitely sub-optimal (mainly because you lose the record of some mount options) but it works for most things and is the only way I could make read-only root work acceptably. I achieve the "always use -n" by replacing /bin/mount with a shell script which add the -n flag and execs the real mount program. It would be better if this was an fstab option, but it is only an interim approach anyway.
(In reply to comment #14) > Moving locks to /var is definitely the clean solution, however, for what its Well, I'd like to see init scripts for the system where is mtab lock in /var/lock and the /var is separate FS. > worth, a viable work around is to make /etc/mtab a symbolic link to > /proc/mounts and always use the -n option to mount and unmount. This is You needn't to use the -n option, because mount(8) is able to detect the mtab symlink. > definitely sub-optimal (mainly because you lose the record of some mount > options) but it works for most things and is the only way I could make I see two problems with the symlink: - user mounts (user= option) - bind mounts (/proc/mounts does not provide all relevant information for umount(8)) The mount(8) (since util-linux 2.14) and kernel (since v2.6.24) support auto-destruction of loop devices. It means we needn't to care about the loop= option any more.
(In reply to comment #13) > It seems that we are not getting anything like union mounts in Fedora any time > soon. *Unfortunately*. It would be nice to found and implement a global solution rather than deform tons of system utils. Why we cannot use a COW devices and write data to RAM disk (like LiveCD)?
> You needn't to use the -n option, because mount(8) is able to detect the mtab > symlink. You are missing the point. It is trying to create /etc/mtab.RANDOMSOMETHING which is impossible because /etc is writable, which is the entire point of wanting locks in another directory. > Why we cannot use a COW devices and write data to RAM disk (like LiveCD)? It would be highly imprudent to dedicate that kind of RAM to a production system that relies on this. Also dm-snap based tracking of changed blocks cannot 'whiteout' changes undone, so more activity there uses more and more RAM eventually leaded to a filesystem panic. This has been a horrible hack for LiveCD to depend on. The other distros do better than this with aufs or unionfs to get around this problem for both LiveCD and read-only root, but we cannot use them because they are unsuitable for the upstream kernel. Adding to F11Blocker.
(In reply to comment #17) > > You needn't to use the -n option, because mount(8) is able to detect the mtab > > symlink. > > You are missing the point. It is trying to create /etc/mtab.RANDOMSOMETHING > which is impossible because /etc is writable, which is the entire point of > wanting locks in another directory. mount(8) does not create any lock file when the mtab file is a symlink BTW, my plan for F11 is to move fstab and mtab code to libmount and use a global /etc/mount.conf where you can define a mtab directory. The long-term plan (F12) is to kill mtab file at all and use /proc/mounts and /proc/self/mountinfo only. (And /var/mount/ for some special userspace mount options.)
With regard to libmount, is there a git/cvs/svn repo somewhere, where its possible to watch this take shape?
git://git.kernel.org/pub/scm/utils/util-linux-ng/util-linux-ng.git branch libmount, but there is nothing useful yet ... I need to found time and push some stuff there.
Using RHEL5.2 this still seems to be a problem, sadly. Will any progress be made soon to clean this little mess up?
*** Bug 487604 has been marked as a duplicate of this bug. ***
This is entirely too late to introduce a change like this for F11. Punting to F12.
unless this is part of some kind of officially approved feature for f12, I'm not quite clear on how it can reasonably be considered as blocking the release? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Discussed at critical bug review meeting. This is not critical for Fedora 12. If it's critical for a related RHEL project, please track that in the context of the RHEL project. Dropping from F12Blocker list. Thanks. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
The libmount won't be ready for F-12/RHEL6, the back up plan is to move the lock files. I'm going to add some extra checks to the locking algorithm and probably /etc/mount.conf where you can define a directory for lock files (e.g. /var/lock).
Move mtab lock HOWTO: - install util-linux-ng >= 2.16-2.fc12 - cp /usr/share/docs/util-linux-ng-2.16/mount.conf /etc - $EDITOR /etc/mount.conf (set MTAB_LOCK_DIR=) Note that you need to use the same lock directory in all /sbin/mount.<type> utils. The default is still /etc. The patch is fedora-specific. The upstream solution will be libmount and system without the mtab file. The /etc/mount.conf should be also supported by the library.
How do people feel about moving the locks to /dev by default? /dev seems to be a good location because it is always read/write tmpfs, mounted by the initrd during bootup. Any reason not to? This should work nicely in all cases?
On second thought, perhaps we should remove this from mount. This interim solution is incomplete because all the mount.* commands and fuse mounts that bypass /bin/mount do not respect the alternate mtab lock location.
I agree. It's really not simple task to fix this problem. It's seem that we need to kill mtab at all. Arbitrary other solution is hack. The patch has been removed from the package.
Created attachment 355734 [details] patch to move mtab locks Just for the record, here is a patch that allows to move mtab locks. It could be useful for crazy people who don't care about /sbin/mount.<type> helpers and use mount(8) only.
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Closing, this issue has to be resolved by upstream (and upstream is working on this issue).
(In reply to comment #35) > (and upstream is working on this issue). Is there upstream thread or git commit for which you can paste the link here?