https://bugzilla.novell.com/show_bug.cgi?id=804544 https://bugzilla.novell.com/show_bug.cgi?id=804544#c1 Jeff Mahoney changed: What |Removed |Added ---------------------------------------------------------------------------- Component|libzypp |libzypp Version|RC 1 |13.1 Beta 1 Product|openSUSE 12.3 |openSUSE Factory --- Comment #1 from Jeff Mahoney 2013-09-19 16:50:48 EDT --- This issue is still in openSUSE 13.1 Beta1. Incidentally, mounting the NFS root and following the path may be a sane way to handle nfs4 mounting. It is exactly what the kernel does. On the server, everything exported via NFS4 has to be in the same namespace. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=804544 https://bugzilla.novell.com/show_bug.cgi?id=804544#c3 --- Comment #3 from Jeff Mahoney 2013-09-20 12:31:31 EDT --- Created an attachment (id=559318) --> (http://bugzilla.novell.com/attachment.cgi?id=559318) Example code to confirm that an NFS4 mount is expected NFS4 involves referrals and submounts for requests that cross remote file system boundaries. e.g. on my server, I have: /nfs4 (root fs) /nfs4/data (btrfs) /nfs4/data/tftpboot/images/openSUSE13.1/x86_64 (loop mounted iso9660) On the client, these appear like this: starscream:/ on /exports/starscream type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp6,timeo=600,retrans=2,sec=sys,clientaddr=2001:470:1f07:5f7:eda7:3faf:37eb:39c6,local_lock=none,addr=2001:470:1f07:5f7::1) starscream:/data on /exports/starscream/data type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp6,port=0,timeo=600,retrans=2,sec=sys,clientaddr=2001:470:1f07:5f7:eda7:3faf:37eb:39c6,local_lock=none,addr=2001:470:1f07:5f7::1) starscream:/data/tftpboot/images/opensuse13.1/x86_64 on /exports/starscream/data/tftpboot/images/opensuse13.1/x86_64 type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp6,port=0,timeo=600,retrans=2,sec=sys,clientaddr=2001:470:1f07:5f7:eda7:3faf:37eb:39c6,local_lock=none,addr=2001:470:1f07:5f7::1) Any of those transitions could have been referred to a different server or follow a server-side symbolic link. The entry in /proc/mounts will reflect the "real" pathname and server that was followed. When libzypp encounters it, it assumes another file system has been mounted instead and failed the confirmation. If the server/path pair doesn't match the requested ones, we can confirm that we have the right file system by mounting the root of the original server and then following the path ourselves. By comparing the st_dev and st_ino of the directories, we can confirm that the right file system has been located. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=804544 https://bugzilla.novell.com/show_bug.cgi?id=804544#c4 Michael Andres changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P1 - Urgent AssignedTo|ma@suse.com |zypp-maintainers@forge.prov | |o.novell.com --- Comment #4 from Michael Andres 2013-09-23 09:47:10 CEST --- I'll have a look at it. AFAIR isAttached was originally written to detect whether devices (CD/HD) are already mounted in order to reuse the existing mounts. Probably not really needed nfs. I'll check how the code mutated throughout the past years. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.