On 08/19/2015 12:04 AM, radomici wrote:
>> Which version of the 'samba-list' package do you have? Mine shows
>> samba-libs-4.1.12-16.1.x86_64

> I have the same one.

That we have different include files for ld.so.conf.d is interesting then.
If I were you I would move that one to something like /root and then run
ldconfig to see if that helps anything. Also you have a few others in
there for other purposes which may or may not be valid on your current
system... I recall some for NVidia in particular which may be valid, but
who knows. If those files were written by NVidia code back when you had
the 11 codebase, perhaps they are just interfering now. Again, moving
them and testing is simple; worst case, move them back and run 'ldconfig'
to re-calculated libraries again and all should be well. Since NVidia
deals with graphics, be able to do this from a reliable remote connection,
just in case the GUI (X/KDE/Ghome) dies somehow.

> Actually, this may indicate a problem. After upgrade to SLED12 I noticed
> most of a third party programs like wine, virtualbox, teamviewer,
> audacity, barracudavpn client, etc. that were originally installed from
> rpm still works (but few do not work) but do not have any associated
> rpm. At least yast do not find them, like they do not exist anymore.
> Could this be the cause of my issue?

Yes, the upgrade probably knew how to upgrade some RPMs, but some RPMs are
created to NOT own some files on purpose. As a result, when you have an
installer like the SLED 12 installer, it does not necessarily know what
all to clean up. It may do everything properly on the RPM side, but those
non-owned files will not be changed without wiping the disk, or a lot of
thorough review done by you manually. Often that's not a big deal, but
sometimes, perhaps this time, you end up cleaning things up yourself to
get everything perfect.

Because of what I saw from your chkbin output, I'm wondering if you may
have other samba4 libraries out there, some which may be referenced by
ghome-control-center, which may be what tries to load the old
libgcrypt.so.11 (and libgnutls.so.26) version. If that is the case,
moving/removing those to something like /root (again, for temporary
storage) may be all that is required to fix that utility. I'd look
specifically at '/usr/lib64/samba/libflag_mapping.so' to see what owns it,
if that's current, etc., just like we did above for the samba
configuration file. If this is a leftover file that happens to be in the
right place to be roped in by other programs, maybe that's it. Again,
cleaning up possibly-old includes for Samba as found under
/etc/ld.so.conf.d/ may help, since those are probably what cause these to
be found.

Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...