Since last kernel upgrade I cannot restart without graphical login failure. The error messages are:
“Could not connect to session bus: Failed to connect to socket /tmp/dbus-randomString:Connection refused”
and after clicking “Close”:
“Could not acquire name on session bus”
My normal user is a network user authenticated via an LDAP server. I tried restarting a few times but no luck. Then I created a new local user and graphical login worked. So my impression was that some session files in my ordinary home directory had been corrupted and I thought that I could simply rename my ordinary home directory and get a new one on login. Not so! Well, perhaps the login would work but it would not help. The reason is that the same problem occurred after a restart when I tried to log in the new local user so my guess is that the same thing will happen every time I create a new user or home directory. Doing this every day is no solution.
No problem with text login.
What now? Is a fresh install the only cure?
Thanks for any help or suggestions that you may have.
I see that I missed that you’re using LDAP-based login - sorry about that!
It’s been a while since I set that up, but I might be inclined to double-
check the PAM configuration that relates to session management - it’s
been a while since I’ve set that up (so it’s likely changed).
Did you use YaST to set this up, or did you set it up manually using the
files in /etc/pam.d?
Did you use YaST to set this up, or did you set it up manually using the
files in /etc/pam.d?
I cannot answer that question, at least not off hand. It was set up by my network systems manager who is now retired so even asking may be tricky. The new people do not favour OpenSuse. Most likely they will tell me to install Ubuntu instead. Of course I would like to avoid a fresh install and hence my asking for help in this forum. I do not mind Ubuntu as such but avoiding a lot of post-install work would be nice. Then again, perhaps the LDAP authentication is similar enough in Ubuntu so that the new people can help me. I guess I’ll find out.
Some years ago I tried to understand how to get Samba to accept LDAP authentication because my network shares don’t get shared with the same Samba config file that worked with the formerly locally authenticated user and the said systems manager never had time to sort it out. Unfortunately, the task proved too time consuming so I had to give it up. My boss doesn’t like when I spend time on issues like this but what to do when the support people refuse? Why did I write this? Well, what I’m trying to say is that I’m probably not very good at exploring the pam.d tree under /etc and I distincly remember a lot of warning voiced when I tried going into that jungle before.
Interestingly, though, I tried also
sudo systemctl status dbus
on the new locally authenticated user I created and then I got this:
Unknown operation dbus.
so it would seem that for some reason dbus is started for the network user but not for the local. Perhaps this info can shed some light over the issue.
I assume you are able to login successfully to a text console and have no problem accessing network resources which use LdAP authentication (possible network shares)?
If so,
I’d recommend changing your Display Manager, If you’re configured to use SDDM, try installing LightDM and then using the YaST “/etc/sysconfig editor” to switch Display Managers.
Note that using YaST to change DMs works only up to openSUSE 42.3, which is about to EOL on June 30. Assuming you will want to upgrade to LEAP 15 or 15.1, this will no longer be the way to switch DMs, you’ll need to do this by an “update-alternatives”
There are plenty of posts in this Forum about this that describe how to do this the new way, or you can ask again.
I tried using Yast to edit /etc/sysconfig/displaymanager but the entry was greyed out so I couldn’t get to it. I opened it manually and apparently the system was set to use kdm. I commented out that line and according to
I don’t know if the YaST module setting can be greyed out. My guess is that you’re not setting your Display Manager correctly, see the following screenshot. You will likely need to type in the “lightdm” as depicted.
As you can see the only non-42.3-repo enabled is amd which is a local repo on my harddrive. Some time ago I experimented with the SLE proprietary driver for Radeon Pro Wx 7100 and actually got it to run but since the build process made an initrd that wouldn’t work I decided to try and make do with the open source driver. To get the system up and running with the proprietary driver I had to replace the non-working initrd with the one built for the open source driver. I realised that this wasn’t something I’d like to do for every kernel upgrade. There is a thread under “Unreviewed how to and FAQ” detailing the whole thing. This was also the reason for enabling the Bumblebee repo.
Other than that the only non-OpenSuse software I have installed recently is LabView and according to NI 42.3 is among the few supported Linux distros.
Good thing you made me do this check because I didn’t know that the MATE repo was not enabled. Perhaps I should enable it since this is my preferred DE. On the other hand I tried a few other DEs before switching to “lightdm” but they didn’t not work so I don’t expect enabling the MATE repo to work any miracles.
I can assure you that displaymanager was indeed greyed out. There was no way “TAB”-ing would reach it. Right now I don’t have the time to take a picture but if you insist I can do that tomorrow. Perhaps the corresponding yast-module is not installed.
> tsu2;2899224 Wrote:
>> I don’t know if the YaST module setting can be greyed out.
>>
>>
> I can assure you that displaymanager was indeed greyed out. There was no
> way “TAB”-ing would reach it. Right now I don’t have the time to take a
> picture but if you insist I can do that tomorrow. Perhaps the
> corresponding yast-module is not installed.
>
> /Gösta
That does seem unusual. Are you running YaST as root? I could see it
being greyed out if it didn’t have access to modify the configuration.
You are quite right. There was no greying out in console yast. It was just me not knowing how to navigate. TAB-ing didn’t do the trick but using arrow-keys did so now I have checked the setting (lightdm) using yast as root (su -, not just sudo). Still no joy, however!
Graphical login is not a total failure. It works with ICEWM so now I don’t have to switch machines and move files all the time. I switched displaymanager to SDDM using yast and rebooted. With SDDM I get to choose WM. Lightdm does not give me this choice.
For several years I used KDE for the desktop but since a few months I use MATE as I could not make Comsol Multiphysic tooltips readable using KDE. I still cannot login graphically using either of those.
I found the culprit. For many years I have used the Anaconda python distribution but have always taken care to keep it separate from the system and I have never allowed the installation script to modify the startup files. I have, however, enabled Anaconda using Environment modules commands in “.bashrc” and this has caused no problems for several years. Apparently the graphical boot sequence has changed so that it is no longer possible to enable Anaconda this way, i.e., .bashrc is read earlier than before. There is a thread here describing the problem: https://forums.opensuse.org/showthread.php/520628-Could-not-start-D-bus-Can-you-call-qdbus-qt5
I found this thread several days ago but as Anaconda never has caused any trouble before I thought I was in the clear. But it was easy enough to comment out the Anaconda lines in .bashrc so it was definitely worth a shot.
I will let the Anaconda people know so that they can put in a “heads-up” for users in the installation script.
As promised I alerted the Anaconda team and suggested a warning to be issued by the installation script. This is the response I got (from Ray Donnelly):
Please ask the SUSE developers to call qtdbus via its full path.
In fact this issue caused quite a bit of stir when it first surfaced a couple of years ago. The link I put in the previous message is only one of several:
and there may be more around. There are pros and cons to every proposed solution and I don’t believe there is a solution that will make everybody happy. Rather, it’s a matter of taste which one you choose. But I believe it would be fair to the end user for every party using qdbus to somehow alert the user that there are other versions of qdbus around that potentially might cause problems. IMHO I’d recommend a warning and perhaps a solution suggested but the end user should be free to choose.