Harald Dunkel wrote: > If I chroot into a subdirectory, then /proc/mounts shows > me 3 mounts for "/". Sample session:
Yes. This is related to the recent move of /etc/mtab from being a file to being a symlink to /proc/mounts. There is a related discussion in Debian Bug#653073 (and GNU bts bug 10363) and I think this issue is really a duplication of that issue. I think they should be merged because the full solution would seem to be the same. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653073 > {root@cecil:~ 752} mount /dev/sdh2 /mnt > {root@cecil:~ 753} mount --bind /proc /mnt/proc > {root@cecil:~ 754} chroot /mnt > # cat /proc/mounts | grep ' / ' > rootfs / rootfs rw 0 0 > /dev/disk/by-uuid/68cc0c8f-306a-44bd-af2d-8441039bae5e / ext4 > rw,noatime,user_xattr,barrier=1,data=ordered,discard 0 0 > /dev/sdh2 / ext4 rw,noatime,user_xattr,acl,barrier=1,data=ordered 0 0 > > Of course only the 3rd line is valid, but how should a script > running within the chroot know? I think the issue isn't whether they are valid, all three are certainly valid, but rather that normally the user only cares about one of them. See especially the comments starting at Bug#653073#65 here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653073#65 > Do you think it would be possible to use the "CLONE_NEWNS" option > for clone(2) to hide all the invalid mount points outside of the new > directory tree? > > Of course I am not sure that coreutils is the right package > to fix this, or if such a change is worth the effort. Please > reassign if necessary. See also this related associated change in the upstream. (It is only slightly confusing that two different BTS instances on different sites are cross-posted to on this bug log. <chuckle>) http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10363#38 Bob -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
