Signed-off-by: Gerardo Exequiel Pozzi vmlinuz386@yahoo.com.ar --- rc.sysinit | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/rc.sysinit b/rc.sysinit index 733149c..6a01029 100755 --- a/rc.sysinit +++ b/rc.sysinit @@ -29,9 +29,9 @@ if ! /bin/mountpoint -q /dev; then fi /bin/mkdir -p /run/lock /dev/{pts,shm} /bin/chmod 1777 /run/lock -/bin/mountpoint -q /dev/pts || /bin/mount /dev/pts &> /dev/null \ +/bin/mountpoint -q /dev/pts || /bin/mount -n /dev/pts &> /dev/null \ || /bin/mount -n -t devpts devpts /dev/pts -o mode=620,gid=5,nosuid,noexec -/bin/mountpoint -q /dev/shm || /bin/mount /dev/shm &> /dev/null \ +/bin/mountpoint -q /dev/shm || /bin/mount -n /dev/shm &> /dev/null \ || /bin/mount -n -t tmpfs shm /dev/shm -o mode=1777,nosuid,nodev
# remount root ro to allow for fsck later on, we remount now to
On Mon, May 16, 2011 at 8:44 AM, Gerardo Exequiel Pozzi vmlinuz386@yahoo.com.ar wrote:
Signed-off-by: Gerardo Exequiel Pozzi vmlinuz386@yahoo.com.ar
rc.sysinit | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/rc.sysinit b/rc.sysinit index 733149c..6a01029 100755 --- a/rc.sysinit +++ b/rc.sysinit @@ -29,9 +29,9 @@ if ! /bin/mountpoint -q /dev; then fi /bin/mkdir -p /run/lock /dev/{pts,shm} /bin/chmod 1777 /run/lock -/bin/mountpoint -q /dev/pts || /bin/mount /dev/pts &> /dev/null \ +/bin/mountpoint -q /dev/pts || /bin/mount -n /dev/pts &> /dev/null \ || /bin/mount -n -t devpts devpts /dev/pts -o mode=620,gid=5,nosuid,noexec -/bin/mountpoint -q /dev/shm || /bin/mount /dev/shm &> /dev/null \ +/bin/mountpoint -q /dev/shm || /bin/mount -n /dev/shm &> /dev/null \ || /bin/mount -n -t tmpfs shm /dev/shm -o mode=1777,nosuid,nodev
# remount root ro to allow for fsck later on, we remount now to
Why doing this ? With /etc/mtab linked to /proc/mounts, why just every time calling in with -n ?
--- El lun 16-may-11, Seblu seblu@seblu.net escribió:
De: Seblu seblu@seblu.net Asunto: Re: [arch-projects] [PATCH] [initscripts] Use mount -n for devpts and shm Para: "Arch Linux projects development discussion" arch-projects@archlinux.org Fecha: lunes, 16 de mayo de 2011, 14:15 On Mon, May 16, 2011 at 8:44 AM, Gerardo Exequiel Pozzi vmlinuz386@yahoo.com.ar wrote:
Signed-off-by: Gerardo Exequiel Pozzi vmlinuz386@yahoo.com.ar
rc.sysinit | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/rc.sysinit b/rc.sysinit index 733149c..6a01029 100755 --- a/rc.sysinit +++ b/rc.sysinit @@ -29,9 +29,9 @@ if ! /bin/mountpoint -q /dev; then fi /bin/mkdir -p /run/lock /dev/{pts,shm} /bin/chmod 1777 /run/lock -/bin/mountpoint -q /dev/pts || /bin/mount /dev/pts
&> /dev/null \
+/bin/mountpoint -q /dev/pts || /bin/mount -n /dev/pts
&> /dev/null \
|| /bin/mount -n -t devpts devpts /dev/pts
-o mode=620,gid=5,nosuid,noexec
-/bin/mountpoint -q /dev/shm || /bin/mount /dev/shm
&> /dev/null \
+/bin/mountpoint -q /dev/shm || /bin/mount -n /dev/shm
&> /dev/null \
|| /bin/mount -n -t tmpfs shm /dev/shm -o
mode=1777,nosuid,nodev
# remount root ro to allow for fsck later on, we
remount now to
Why doing this ? With /etc/mtab linked to /proc/mounts, why just every time calling in with -n ?
Hello,
1) To be consistent with other mounts calls. 2) Currently (util-linux-2.19-2) mount is not linked against libmount, there is no support for utab. Symlink mtab will loss userspace mount features. 3) This does not affect if mtab is symlinked.
On Mon, May 16, 2011 at 7:15 PM, Seblu seblu@seblu.net wrote:
On Mon, May 16, 2011 at 8:44 AM, Gerardo Exequiel Pozzi vmlinuz386@yahoo.com.ar wrote:
Signed-off-by: Gerardo Exequiel Pozzi vmlinuz386@yahoo.com.ar
rc.sysinit | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/rc.sysinit b/rc.sysinit index 733149c..6a01029 100755 --- a/rc.sysinit +++ b/rc.sysinit @@ -29,9 +29,9 @@ if ! /bin/mountpoint -q /dev; then fi /bin/mkdir -p /run/lock /dev/{pts,shm} /bin/chmod 1777 /run/lock -/bin/mountpoint -q /dev/pts || /bin/mount /dev/pts &> /dev/null \ +/bin/mountpoint -q /dev/pts || /bin/mount -n /dev/pts &> /dev/null \ || /bin/mount -n -t devpts devpts /dev/pts -o mode=620,gid=5,nosuid,noexec -/bin/mountpoint -q /dev/shm || /bin/mount /dev/shm &> /dev/null \ +/bin/mountpoint -q /dev/shm || /bin/mount -n /dev/shm &> /dev/null \ || /bin/mount -n -t tmpfs shm /dev/shm -o mode=1777,nosuid,nodev
# remount root ro to allow for fsck later on, we remount now to
Thanks for the patch!
Why doing this ? With /etc/mtab linked to /proc/mounts, why just every time calling in with -n ?
We don't yet have the symlink, until we do we should use "-n" here.
I'm planning to look into the remaining downsides of using libmount and symlinking mtab to /proc/self/monuts, to see if we can make the switch. "The others" are doing it, so hopefully we can join soon. If anyone knows of problems, I'd be interested to know.
Cheers,
Tom
On Mon, May 16, 2011 at 08:13:46PM +0200, Tom Gundersen wrote:
On Mon, May 16, 2011 at 7:15 PM, Seblu seblu@seblu.net wrote:
On Mon, May 16, 2011 at 8:44 AM, Gerardo Exequiel Pozzi vmlinuz386@yahoo.com.ar wrote:
Signed-off-by: Gerardo Exequiel Pozzi vmlinuz386@yahoo.com.ar
rc.sysinit | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/rc.sysinit b/rc.sysinit index 733149c..6a01029 100755 --- a/rc.sysinit +++ b/rc.sysinit @@ -29,9 +29,9 @@ if ! /bin/mountpoint -q /dev; then fi /bin/mkdir -p /run/lock /dev/{pts,shm} /bin/chmod 1777 /run/lock -/bin/mountpoint -q /dev/pts || /bin/mount /dev/pts &> /dev/null \ +/bin/mountpoint -q /dev/pts || /bin/mount -n /dev/pts &> /dev/null \ || /bin/mount -n -t devpts devpts /dev/pts -o mode=620,gid=5,nosuid,noexec -/bin/mountpoint -q /dev/shm || /bin/mount /dev/shm &> /dev/null \ +/bin/mountpoint -q /dev/shm || /bin/mount -n /dev/shm &> /dev/null \ || /bin/mount -n -t tmpfs shm /dev/shm -o mode=1777,nosuid,nodev
# remount root ro to allow for fsck later on, we remount now to
Thanks for the patch!
Why doing this ? With /etc/mtab linked to /proc/mounts, why just every time calling in with -n ?
We don't yet have the symlink, until we do we should use "-n" here.
I'm planning to look into the remaining downsides of using libmount and symlinking mtab to /proc/self/monuts, to see if we can make the switch. "The others" are doing it, so hopefully we can join soon. If anyone knows of problems, I'd be interested to know.
Cheers,
Tom
We had some fallout when we inititally did this on the launch of 2.19:
https://bugs.archlinux.org/task/23014
I'm not sure if this was ever reported to upstream or what the current status of this is.
d
On Mon, May 16, 2011 at 8:27 PM, Dave Reisner d@falconindy.com wrote:
We had some fallout when we inititally did this on the launch of 2.19:
https://bugs.archlinux.org/task/23014
I'm not sure if this was ever reported to upstream or what the current status of this is.
Thanks for the poiner Dave. However, from the comment on that bug it seems that we did not actually symlink mtab, just enabled the libmonut, and that this might have caused the problem.
I'll be looking into this in the near future with the aim of making the switch relatively soon (if there are no known problems or open bug reports against the distros who have made the change).
Cheers,
Tom
On Mon, May 16, 2011 at 08:32:10PM +0200, Tom Gundersen wrote:
On Mon, May 16, 2011 at 8:27 PM, Dave Reisner d@falconindy.com wrote:
We had some fallout when we inititally did this on the launch of 2.19:
https://bugs.archlinux.org/task/23014
I'm not sure if this was ever reported to upstream or what the current status of this is.
Thanks for the poiner Dave. However, from the comment on that bug it seems that we did not actually symlink mtab, just enabled the libmonut, and that this might have caused the problem.
I'll be looking into this in the near future with the aim of making the switch relatively soon (if there are no known problems or open bug reports against the distros who have made the change).
Cheers,
Tom
It's definitely the cause of the problem. What isn't clear is if upstream supports /etc/mtab as its own file when mount is linked against libmount.
I, personally, have no arguments against modifying the initscripts to enforce the symlink and coordinate it with a util-linux rebuild, but I'm not sure others agree.
dave
On Mon, May 16, 2011 at 8:36 PM, Dave Reisner d@falconindy.com wrote:
On Mon, May 16, 2011 at 08:32:10PM +0200, Tom Gundersen wrote:
On Mon, May 16, 2011 at 8:27 PM, Dave Reisner d@falconindy.com wrote:
We had some fallout when we inititally did this on the launch of 2.19:
https://bugs.archlinux.org/task/23014
I'm not sure if this was ever reported to upstream or what the current status of this is.
Thanks for the poiner Dave. However, from the comment on that bug it seems that we did not actually symlink mtab, just enabled the libmonut, and that this might have caused the problem.
I'll be looking into this in the near future with the aim of making the switch relatively soon (if there are no known problems or open bug reports against the distros who have made the change).
Cheers,
Tom
It's definitely the cause of the problem. What isn't clear is if upstream supports /etc/mtab as its own file when mount is linked against libmount.
I, personally, have no arguments against modifying the initscripts to enforce the symlink and coordinate it with a util-linux rebuild, but I'm not sure others agree.
I switch some times ago with a /etc/mtab linked to /proc/self/mounts and fuse works well.
smbnetfs on /home/seblu/samba type fuse.smbnetfs (rw,nosuid,nodev,relatime,user_id=18136,group_id=2008) user and group are present.
As far i understand bug in #23014, it's due to a too recent util-linux which write permissions of mounts into /proc/self/mount rather than in /etc/mtab. So fuse cannot unmount or see something.
About Gerardo's patch, if we fix symlinks from /etc/mtab to /proc/self/mounts, we can always to mount -n, because writing mtab will not be necessary.
Am 16.05.2011 20:13, schrieb Tom Gundersen:
I'm planning to look into the remaining downsides of using libmount
Downside: It has bugs that need to be reported and fixed.
On Tue, May 17, 2011 at 8:32 AM, Thomas Bächler thomas@archlinux.org wrote:
Am 16.05.2011 20:13, schrieb Tom Gundersen:
I'm planning to look into the remaining downsides of using libmount
Downside: It has bugs that need to be reported and fixed.
Do you know of any examples? AFAIK it is being released in fedora 15 and the next opensuse, so I guess that will shake out any remaining bugs.
-t
Am 17.05.2011 12:04, schrieb Tom Gundersen:
On Tue, May 17, 2011 at 8:32 AM, Thomas Bächler thomas@archlinux.org wrote:
Am 16.05.2011 20:13, schrieb Tom Gundersen:
I'm planning to look into the remaining downsides of using libmount
Downside: It has bugs that need to be reported and fixed.
Do you know of any examples? AFAIK it is being released in fedora 15 and the next opensuse, so I guess that will shake out any remaining bugs.
The fuse bug that was already mentioned. Maybe libmount actually requires mtab as a symlink to mounts, but I think it should still work in both scenarios (maybe we need to clarify this on their mailing list).
Other than that, before getting rid of mtab, all other mount programs should use libmount, too.
arch-projects@lists.archlinux.org