Bug 710269

Fixed in libzypp-9.10.1

MountEntry is 
  "//dist/install/ on /var/adm/mount/AP_0x00000001 type cifs \
   (ro,relatime,unc=\dist\install,username=,domain=suse.de"

But "Looking for media(cifs<//dist/install>)attached(*/var/adm/mount/AP_0x00000001)".

The trailing '/' in "//dist/install/" seems to be the problem when comparing the entries.

Please check bnc#681091.
Maybe the same story with nfs.

I added 'entry.type == "nfs" ||' to line 
if ( ( entry.type == "nfs" || entry.type == "cifs" || entry.type == "smb" )
      ^^^^^^^^^^^^^^^^^^^^^^^
from libzypp-9.10.1 Mount.cc and it works for me now.

*** Bug 681091 has been marked as a duplicate of this bug. ***

Fixed in libzypp-9.10.2

Well, factory nfs install (with libzypp-9.11.0-2.2.i586.rpm) still fails in this very same way.

I can mount the install target manually just fine, but YaST2 fails with:

[retranslated from german]
Cannot create repository from URL 'nfs://serverip/srv/suse/factory/oss'

Details:
mount of URL to mount point failed: unable to verify that the media was mounted.

The y2log is attached.

More observations: the nfsopts=vers=3 initrd argument doesn't seem to have any effect for YaST.

My PXE 
label fact
    kernel susefactory
    append initrd=susefactory-rd vga=791 splash=silent console=ttyS0,115200n8 console=tty0 usedhcp=1 lang=de_DE install=nfs://172.16.23.110/srv/suse/factory/oss?device=eth0 nfsopts=vers=3

Created attachment 451557 [details]
y2log of failed nfs install attempt

Great, looking for 
  'nfs://172.16.23.110/srv/suse/factory/oss' 
but proc/mounts says 
  '172.16.23.110:/local/factory/oss on /var/adm/mount/AP_0x00000001'.

Maybe the kernel guys can tell me how to tell whether 'nfs://172.16.23.110/srv/suse/factory/oss' is already mounted; i.e. that '/local/factory/oss' and '/srv/suse/factory/oss' is in fact the same?

*** Bug 619648 has been marked as a duplicate of this bug. ***

Hi Michael,

sorry for that, but yes, /srv/suse/factory is (relatively) symlinked to /local/factory indeed, and I would like to keep it that way.

But if I change the install argument accordingly, I can easily avoid this issue:

label fact
    kernel susefactory
    append initrd=susefactory-rd vga=791 splash=silent console=ttyS0,115200n8 console=tty0 usedhcp=1 lang=de_DE install=nfs://172.16.23.110/local/factory/oss?device=eth0 nfsopts=vers=3

If the symlink is really the issue in question, that would work, no?

Well, it does not. See newly attached log.

Created attachment 451772 [details]
y2log of failed nfs install attempt without symlink interference

FWIW, the problem persists with current factory build as of yesterday. 

Is there anything, I can do for you to help getting this fixed?

It's a real pity, that 11.4 has gone by with this major regression "included", which solidly prevents this distribution to be _really_ useful for me. (Well it raises the  hurdles for some install scenarios just high enough to renounce the hassle...)

Hence my hand waving here..

Ping

Michael, I can imagine, that you're very busy with other issues, but a short response like: "wait a little", "will not fix for 12.1", "will remove any nfs and smb install source targets from libzypp and yast soon" or "cannot see any issue here" would be really appreciated.

Sorry - I try to fix this for 12.1...

Does it work for you If you if you're using the nfs4 schema (nfs4://serverip/srv/suse/factory/oss)?

Looks like the media handler gets confused because nfs:// (mount -t nfs) later appears as 'type nfs4' in the mount table (/proc/mounts).

Fixed for Factory/12.1 in libzypp-10.1.1
for SLE11SP2 in libzypp-9.11.1
for 11.4 in libzypp-8.13.1

@Hans-Peter: Thanks for being patient, but strongheaded.


@maintenance: Probably something for the next 11.4 libzypp update.

for 11.3 in libzypp-7.9.10

These are great news, Michael.

The the best part of it, factory is installable via NFS again.

Thanks,
Pete

The SWAMPID for this issue is 43736.
This issue was rated as low.
Please submit fixed packages until 2011-11-16.
Also create a patchinfo file using this link:
https://swamp.suse.de/webswamp/wf/43736

please also submit related packages (zypper packagekit, yast2-pkg-bindings, libsatsolver etc for 11.4 ) and I'll pick it up as well. no update for 11.3 for now.

- libsatsolver/libzypp/zypper are up to date.
- asked Ladislav to check the yast2-pkgbindings 
- I'm going to check pkgkit

- PackageKit is waiting for bnc#679650 to be fixed

the P1 was not for the current product

closing

Update released for: PackageKit, PackageKit-branding-upstream, PackageKit-browser-plugin, PackageKit-browser-plugin-debuginfo, PackageKit-debuginfo, PackageKit-debugsource, PackageKit-devel, PackageKit-doc, PackageKit-gstreamer-plugin, PackageKit-gstreamer-plugin-debuginfo, PackageKit-gtk-module, PackageKit-gtk-module-debuginfo, PackageKit-gtk3-module, PackageKit-gtk3-module-debuginfo, PackageKit-lang, libpackagekit-glib2-14, libpackagekit-glib2-14-debuginfo, libpackagekit-glib2-devel, libpackagekit-qt-devel, libpackagekit-qt14, libpackagekit-qt14-debuginfo, libpackagekit-qt2-2, libpackagekit-qt2-2-debuginfo, libpackagekit-qt2-devel, libzypp, libzypp-debuginfo, libzypp-debugsource, libzypp-devel
Products:
openSUSE 11.4 (debug, i586, x86_64)

I update to libzypp-8.13.1 from UPDATE repository of openSUSE 11.4 and try to use my private repository mirror via NFS. I still have the same error as mentioned above:

The NFS mount is created in /var/adm/mount/AP_0x00000001, the following lines show

MediaHandler.cc(checkAttached):604 MountEntries: { ... 
604 192.168.100.2:/srv/openSUSE-repository-11.4/Kernel:/stable/standard/ on ...

that the mount as available, but the negative message follows immediately

MediaHandler.cc(checkAttached):615 Attached media not in mount table ...

and so on. This repeats a lot of times. 

zypp++ seems not to recognize the existing mount, which I can also see in /proc/mounts of course. 

This also happens with host names instead of IP addresses. It doesn't matter if I check the NFS4 check box or not. I can also mount the nfs server without any problem manually.

BTW, I use the current stable kernel 3.2.1 but this also happened already with 2.6.39.

I want to reopen this bug for openSUSE 11.4 

The above mentioned fix in libzypp-8.13.1 for openSUSE 11.4 is not changing the wrong behavior of zypp++ as described in my comment above. 

I still can not use NFS with zypper to connect to my private repository mirror.

Thanks
Ralf

Please attach the zypper logfile /var/log/zypper.log (or an older /var/log/zypper.log-YYYYMMDD.bz2) that shows the reported behavior.  You can execute 'grep main.cc /var/log/zypper.log' (or 'zgrep main.cc /var/log/zypper.log-YYYYMMDD.bz2') to see execution dates and commands the log contains.

Created attachment 472358 [details]
requested zypper.log 

This file ends Jan. 19th although I did some updated over the days after. At least it contains the version information of the libzypp as 
libzypp: 8.13.1 built Dec  1 2011 12:54:14
and
satsolver: 0.16.3

I hope this helps.

Created attachment 472359 [details]
additionally my y2log with the error extract

Update released for: curl, curl-debuginfo, curl-debugsource, libcurl-devel, libcurl4, libcurl4-32bit, libcurl4-x86, libsatsolver, libsatsolver-debuginfo, libsatsolver-debugsource, libsatsolver-demo, libsatsolver-devel, libzypp, libzypp-debuginfo, libzypp-debugsource, libzypp-devel, perl-satsolver, python-satsolver, ruby-satsolver, satsolver-tools, yast2-packager, yast2-pkg-bindings, yast2-pkg-bindings-debuginfo, yast2-pkg-bindings-debugsource, yast2-pkg-bindings-devel-doc, yast2-wagon, zypper, zypper-debuginfo, zypper-debugsource
Products:
SLE-DEBUGINFO 11-SP1 (i386, ia64, ppc64, s390x, x86_64)
SLE-DESKTOP 11-SP1 (i386, x86_64)
SLE-POS 11-SP1 (i386, x86_64)
SLE-SDK 11-SP1 (i386, ia64, ppc64, s390x, x86_64)
SLE-SERVER 11-SP1 (i386, ia64, ppc64, s390x, x86_64)
SLE-SERVER 11-SP1-TERADATA (x86_64)
SLES4VMWARE 11-SP1 (i386, x86_64)

Update released for: libsatsolver, libsatsolver-debuginfo, libsatsolver-demo, libsatsolver-devel, libzypp, libzypp-debuginfo, libzypp-devel, osa-dispatcher, osad, satsolver-tools, spacewalk-backend, spacewalk-backend-app, spacewalk-backend-applet, spacewalk-backend-config-files, spacewalk-backend-config-files-common, spacewalk-backend-config-files-tool, spacewalk-backend-iss, spacewalk-backend-iss-export, spacewalk-backend-libs, spacewalk-backend-package-push-server, spacewalk-backend-server, spacewalk-backend-sql, spacewalk-backend-sql-oracle, spacewalk-backend-sql-postgresql, spacewalk-backend-tools, spacewalk-backend-xml-export-libs, spacewalk-backend-xmlrpc, spacewalk-backend-xp, zypp-plugin-spacewalk, zypper, zypper-debuginfo
Products:
SLE-SERVER 10-CLIENT-TOOLS (i386, ia64, ppc, s390x, x86_64)

(In reply to comment #29)
> I want to reopen this bug for openSUSE 11.4 
> 
> The above mentioned fix in libzypp-8.13.1 for openSUSE .11.4 is not changing the
> wrong behavior of zypp++ as described in my comment above. 

Unfortunately you are right. The nfs/nfs4 issue was fixed for 11.4, but not the initial issue: kernel leaving trailing '/'es in /etc/mtab or /proc/mounts, which may lead to mount table lookup failure. Sorry.

Finally fixed in libzypp-8.13.5

openSUSE-RU-2012:0696-1: An update that has 6 recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 679322,710269,716972,719690,740764,749418
CVE References: 
Sources used:
openSUSE 11.4 (src):    libqdialogsolver1-1.3.0-11.2, libsatsolver-0.16.3-28.1, libzypp-8.13.5-15.1, libzypp-bindings-0.5.9-9.1, libzypp-testsuite-tools-4.2.11-9.1, zypper-1.5.9-12.1