On Thu, Jul 07, 2011 at 09:27:11PM +0200, Michael Biebl wrote: > Am 30.05.2011 15:25, schrieb David Riebenbauer: > > * Tollef Fog Heen <[email protected]> [2011-05-30 13:17]: > >> ]] "A. Costa" > >> > >> | I'd close this bug, but am hesitant. It would be better if the > >> | 'systemd' installation script took care of this '/etc/mtab' detail, or > >> | at least prompted the user. Perhaps this is a 'wishlist' bug then. > >> > >> Yeah, I can make it warn on installation. > > > > I haven't investigated if this is really a good idea or not, yet. But, > > what about letting systemd bind-mount /proc/mounts over /etc/mtab. > > bind-mounting /proc/mounts to /etc/mtab doesn't work. > > What we want is /etc/mtab being a symlink to /proc/self/mounts and with > util-linux 2.19.1-2 in unstable we are a step closer to that. > IIRC there are still some issues with bind mounts and certain file systems > like nfs. > > Question is, where this conversion should be done.
There are a few things to consider here: 1) We can't doing the conversion at package upgrade time without risking breakage. This is due to the fact that /etc/mtab may contain mount options not in /proc/mounts (and there won't necessarily be any usage of /run/mount/utab). Doing it at boot time ensures we start from a clean slate, and store any additional options in utab (I think--I haven't tested this due to not using any filesystems which require it). 2) Currently, it's the responsibility of initscripts (/etc/init.d/mtab.sh) to create the initial mtab. Presumably systemd does something similar to "replay" the mount commands run prior to this point to create it. 3) util-linux would be a logical place for it, given that it's associated with mount. But since it needs doing at boot time and mtab.sh already contains the logic to create it, mtab is probably the best choice--it's just a couple of lines to add to an already existing script that's dedicated to the job. Another consideration is that we probably only want to make the switch to a symlink if we're running a sufficiently recent kernel (2.6.26). I think this is way lower than the minimum supported kernel version, in squeeze, so probably safe to do it unconditionally. However, in the case that we can't link to /proc/mounts, are there any situations where we would want to retain the old mtab.sh behaviour as a fallback? I'm thinking of upgrade scenarios with old kernel versions, missing /proc or any other circumstance which could result in a broken system? If there are no situations where we would want to retain /etc/mtab as a file, we can just create it as a symlink unconditionally in mtab.sh. We really do need libmount support in nfs-utils before making the switch though. Probably also in a couple of other tools. If anyone else has time to do that, that would be great, because I'm afraid I'm a little tied up writing my PhD thesis for the next couple of months. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
signature.asc
Description: Digital signature
