"Gnome Settings" broken after update

I also ran this command,

The log mentions this,
gnome-control-center: error while loading shared libraries: libwbclient.so.0: cannot open shared object file: No such file or directory
every time I try to use settings seems to be culprit,

Running this completed with no errors, but still leaves the Gome settings un-responsive, and returning the same error in the journal
gnome-control-center: error while loading shared libraries: libwbclient.so.0: cannot open shared object file: No such file or directory
as before.
this is the output to
dnf repoquery --whatrequires libwbclient.so.0
Last metadata expiration check: 0:24:23 ago on Wed 07 Aug 2019 22:15:50 BST.
libwbclient-devel-2:4.10.2-0.fc30.i686
libwbclient-devel-2:4.10.6-0.fc30.i686
samba-client-libs-2:4.10.2-0.fc30.i686
samba-client-libs-2:4.10.6-0.fc30.i686
samba-libs-2:4.10.2-0.fc30.i686
samba-libs-2:4.10.6-0.fc30.i686
samba-winbind-modules-2:4.10.2-0.fc30.i686
samba-winbind-modules-2:4.10.6-0.fc30.i686
sssd-libwbclient-devel-0:2.1.0-2.fc30.i686
sssd-libwbclient-devel-0:2.2.0-3.fc30.i686

none of these seem to mention gnome

As there are no SELinux errors, I assume there’s no need to restore the context.

You can also try to troubleshoot the issue with strace, but I don’t think it’s worth the time.

So, just try to reinstall the package and its dependencies:

sudo dnf reinstall gnome-control-center\* $(dnf repoquery \
    --requires --resolve --queryformat "%{NAME}" gnome-control-center)

Or reinstall everything:

sudo dnf reinstall $(dnf repoquery --installed --queryformat "%{NAME}")

Although it seems somewhat excessive, the probability to solve the issue is quite high.

Here’s another path to go about libwbclient.so.0

Let’s look, which packages provide it:

sudo dnf provides '*/libwbclient.so.0'

I won’t post the result here, but we’ll see that package libwbclient (both x86_64 and i686) does provide it.

So it’s likely you need a 64-bit version of this package. And indeed, libwbclient.x86_64 is installed on my system (and no i686 version).

@evelyn, please try to install 64-bit version of this package:

sudo dnf install libwbclient

should be enough on 64-bit system. Also you can emphasize you want x86_64 specifically (though it shouldn’t be needed):

sudo dnf install libwbclient.x86_64

And try to run gnome-control-center once more.

If it refuses to run with the same error, then try to reinstall the package in question:

sudo dnf reinstall libwbclient.x86_64

This command actually installs 32-bit version of the above mentioned package and I’m ready to bet we don’t need it – as I don’t have it installed on my system. So I would suggest to remove it:

sudo dnf remove libwbclient.i686
And here's some additional details for anyone interested.

Though it’s likely that @evelyn won’t be able to trace this path on affected system, at the very least it can be used by others to help her.

We know that the problem is with libwbclient.so.0 library when trying to launch gnome-control-center.

Let’s look at where gnome-control-center binary does want to see this .so library, then check the files this points to. I won’t explain each step, the commands are quite self-explanatory, I think. I’ll answer questions if any would arise.

[myuser@myhost ~]$ which gnome-control-center
/usr/bin/gnome-control-center

[myuser@myhost ~]$ ldd /usr/bin/gnome-control-center | grep libwbclient
	libwbclient.so.0 => /lib64/libwbclient.so.0 (0x00007f67e2e71000)

[myuser@myhost ~]$ file /lib64/libwbclient.so.0 
/lib64/libwbclient.so.0: symbolic link to libwbclient.so.0.15

[myuser@myhost ~]$ file /lib64/libwbclient.so.0.15
/lib64/libwbclient.so.0.15: symbolic link to /etc/alternatives/libwbclient.so.0.15-64

[myuser@myhost ~]$ file /etc/alternatives/libwbclient.so.0.15-64
/etc/alternatives/libwbclient.so.0.15-64: symbolic link to /usr/lib64/samba/wbclient/libwbclient.so.0.15

[myuser@myhost ~]$ sudo dnf provides '/usr/lib64/samba/wbclient/libwbclient.so.0.15'

Repo        : fedora
Matched from:
Filename    : /usr/lib64/samba/wbclient/libwbclient.so.0.15

libwbclient-2:4.10.6-0.fc30.x86_64 : The winbind client library
Repo        : @System
Matched from:
Filename    : /usr/lib64/samba/wbclient/libwbclient.so.0.15

libwbclient-2:4.10.6-0.fc30.x86_64 : The winbind client library
Repo        : updates
Matched from:
Filename    : /usr/lib64/samba/wbclient/libwbclient.so.0.15

So we're back to the same **libwbclient** package, 64bit version.

1 Like

I saw a recommendation somewhere quite a long time ago to always prepend file name with ‘*/’ for provides as you usually don’t know for sure where the file in question should reside.

3 Likes

And actually, please look at man dnf for explanation, the situation with provides is even more complex/interesting.

Here's the quote from the manpage with my musings (I think, not exactly relevant to @evelyn's problem, so I'll hide it.
Provides Command
    dnf [options] provides <provide-spec>
           Finds the packages providing the given <provide-spec>. This is useful when one 
           knows a filename and wants to find what package (installed or not) provides this file.
           The <provide-spec> is gradually looked for at following locations:

           1. The <provide-spec> is matched with all file provides of any available package:

                 $ dnf provides /usr/bin/gzip
                 gzip-1.9-9.fc29.x86_64 : The GNU data compression program
                 Matched from:
                 Filename    : /usr/bin/gzip

           2. Then all provides of all available packages are searched:

                 $ dnf provides "gzip(x86-64)"
                 gzip-1.9-9.fc29.x86_64 : The GNU data compression program
                 Matched from:
                 Provide     : gzip(x86-64) = 1.9-9.fc29

          3. DNF  assumes  that  the <provide-spec> is a system command, prepends it with 
              /usr/bin/, /usr/sbin/ prefixes (one at a time) and does the file provides search again. 
              For legacy reasons (packages that didn't do UsrMove) also /bin and /sbin prefixes 
              are being searched:

                $ dnf provides zless
                gzip-1.9-9.fc29.x86_64 : The GNU data compression program
                Matched from:
                Filename    : /usr/bin/zless

          4. If this last step also fails, DNF returns "Error: No Matches found".

So basically provides libwbclient.so.0 matches with entry in Provide section of package’s spec on step 2.

When provides ‘*/libwbclient.so.0’ matches with a filename, I presume on step 1.

So specifying ‘*/libwbclient.so.0’ prevents dnf provides from finding matches in Provide sections of package’s specs. It’s worth noting, I think.

Though I have to say, my intention for using provides usually (maybe even always) was exactly to look up filename matches, not “Provide” section matches.

2 Likes

This post has a lot of good troubleshooting info, does it have to be deleted?

1 Like

It’s not mine post but the following are important, so I try to keep the thread as clean as possible.
I read the dnf documentation in the past, but it seems a bit too long ago, so I start to forget about some of the features.

1 Like

I tried this,

And this was the result,

Package libwbclient-2:4.10.6-0.fc30.x86_64 is already installed.
Package libwbclient-2:4.10.6-0.fc30.i686 is already installed.
Dependencies resolved.
Nothing to do.
Complete!

would it have shown if these were present but corrupted in some way?
I also ran

to remove as suggested

sudo dnf reinstall libwbclient libwbclient.x86_64
1 Like

Thanks all this was the command that needed to be input, gnome settings works properly now.

My first journey into command line, a bit scary, but I will be reading a lot on man files, I hadn’t read many.
Starting with dnf

1 Like

Hi @evelyn! Congratulations of successfully solving you issue )

I’ve encountered recommendation by Ask Fedora admins to

  1. Mark the post that contains the aswer to your problem as a solution. This

    • marks entire thread as solved and

    • allows people with similar problem in the future to jump to solution quickly without the need to read through the whole thread.

  2. Not to add word “Solved” to the thread’s title (as step 1 clearly marks the thread as solved).

I don’t demand anything from you, I just share what I’ve seen / heard / was told.


From my experience, cli is a really wonderful, clean and versatile instrument. And while on Windows it always was (and still is) clunky and quite uncomfortable to use – !!! – on Linux it’s very user-friendly, very convenient, you can do so much with cli and it’s so easy (and natural!) to do certain things on cli and not in a GUI. It’s clear a lot of people put a lot of effort and love to make it a really great instrument / experience :slight_smile:

I’m quite sure that when you start to use it – even if only for a bit from time to time, lets say only to update your system and install/remove packages at first – it’ll quickly becomes not scary but friendly to you )

From my personal experience – reading whole man pages could be quite daunting, as they can be very comprehensive. Though it’s still a good thing to do – if not a whole page, then at least skip thorough and look for options / topics you need. Use search: enter /provides and press [Enter] to search man page for the word “provides”, then press [n] to jump to next results.

Use tab completion – like, always :slight_smile: Makes working in a cli a lot easier and faster. Look it up if you’ve never heard of it.

One more command that can be quite useful is “cheat”. Install it with

sudo dnf install cheat

Then try, for example

cheat dnf

and also

cheat cheat
1 Like

Yes, please :slight_smile:
https://discussion.fedoraproject.org/t/welcome-to-ask-fedora-please-read-me-first/69479
https://fedoraproject.org/wiki/Ask_fedora_guidelines

Sorry, had overlooked the check box, I see it has been checked for me,

I had read both these a while ago, but obviously forgotten the contents, will re-read

3 Likes

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.