There may be simpler ways, but this works:
cat /etc/alternatives/default-displaymanager | grep -i DISPLAYMANAGER=
SDDM
paul@HP255G7:~> cat /etc/alternatives/default-displaymanager | grep -i DISPLAYMANAGER=
DISPLAYMANAGER=/usr/bin/lightdm
paul@HP255G7:~>
@Paul:
Great!!! Thanks for sharing that . . . I’m over in the troubled machine in another OS . . . I’ll reboot over to TW partition in a minute and see what’s what with it . . . .
Yeh right… That’s what comes of being interrupted mid post.
That should have been
SDDM, if in use, will be shown as “DISPLAYMANAGER=/usr/bin/sddm” whereas this machine is currently using LightDM:
But I guess you probably figured that one anyway.
@Paul:
More or less figured that it would show what was in use . . . . So, over in the offending machine in the offending TW OS . . . the one where the problem first showed up . . . get to the TW “splash” with the revolving circle, then goes to black for the log in screen with the vertical cursor as the only thing visible . . . type the password and it logs into GUI and all is well . . . .
Just for kicks I ran the zypper ref/dup and nothing is locked (I believe) and it showed a bunch of packages to install, ran through that and rebooted . . . problem still there. I ran your cat command:
sudo cat /etc/alternatives/default-displaymanager | grep -i DISPLAYMANAGER=
[sudo] password for root:
DISPLAYMANAGER=/usr/sbin/lightdm
I believe that lightdm is likely the default for MATE, but over in my desktop it was showing the questions about MATE-menu and python3 as not being in sync as the problem . . . this machine is where the problem started and I selected another option. In the desktop I selected “keep obsolete python3” and that package is now locked and ithe desktop never had the black log in screen that this computer is still showing . . . . But, in the laptop, when the problem first showed up it gave me the same “choose from the following options questions on mate-menu vs python3” . . . but I picked another answer and the problem has continued, but the questions have also not been asked since . . . .
All that to say, would that be a DM issue if only the log in window is black, and once logged in, it’s operational???
I ran your “su” command as well just for kicks:
update-alternatives --config default-displaymanager
There are 3 choices for the alternative default-displaymanager (providing /usr/lib/X11/displaymanagers/default-displaymanager).
Selection Path Priority Status
- 0 /usr/lib/X11/displaymanagers/lightdm 15 auto mode
1 /usr/lib/X11/displaymanagers/console 5 manual mode
2 /usr/lib/X11/displaymanagers/lightdm 15 manual mode
3 /usr/lib/X11/displaymanagers/xdm 10 manual mode
Press <enter> to keep the current choice
[li], or type selection number[/li]
I only responded to this as a result of your reference to SDDM in post #36, My knowledge of the Mate DE is nil.
However, let’s try and address one problem at a time and try and resolve the blank DM greeter screen. Just to confirm, although the screen is blank you’re still able to login.
A couple of preliminaries, after having logged in can you post the output of these:
sudo cat /proc/cmdline
sudo zypper lr -d
Having obtained those, logout from the desktop session and switch to a virtual terminal (ctrl-alt-F2) and log in as your normal user.
Let’s try saving the existing configuration of LightDM and then do a forced re-install:
sudo mv /etc/lightdm /etc/lightdm-saved
sudo zypper in -f lightdm
Now reboot
sudo shutdown -r now
and see if the DM greeter screen is displayed - then we’ll take it from there…
Afterthought… Prior to the above. Have you changed anything in /etc/lightm/lightdm.conf ?
@Paul:
Thanks kindly for your interest in helping me out with this problem . . . a bit jammed today to mess with it, although your suggestions to reinstall lightdm look relatively benign . . . my question remains on why the DM would have problems with log in screen, but then once password is typed, GUI is fine??
I mentioned “sddm” in #36, because I might have found a thread on the forum where “black log in screen” was mentioned, and I might even have seen a post from you on the problems of living with sddm??? So I was just looking to get some attention to my personal issues . . . . : - )))
Seems like there are a number of threads where similar outcomes are resulting from upgrades . . . hard to parse through them to catch the marrow of it. In my case because in the three TW distros that I have on two machines, running MATE . . . all of them had this “What would you like to do?” question involving “mate-menu” keeping or breaking it, and/or keeping or breaking python3-xdg??? I’m figuring that the problem resides there . . . and in keeping the “obsolete python” package on my desktop, prevented the black screen problem . . . but on the new linux laptop, I made another choice . . . I was in a hurry and instead of aborting out of it, I picked possibly #1 . . . because . . . it was #1??? And that is what brought on the case of the blackening log in process . . . not a show-stopper, but more of an annoyance . . . .
PS: To answer your .conf question, no I didn’t do anything intentionally to such a file, I mostly run multi-boot, so all I have time for is zyppering dup -l . . . and moving on to the next one . . . .
Got these two problems in my desktop install of TW:
Loading repository data...
Reading installed packages...
Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command.
Computing distribution upgrade...
2 Problems:
Problem: nothing provides libhogweed.so.5()(64bit) needed by librtmp1-2.4.20151223.fa8646d-1.53.x86_64
Problem: mate-menu-20.04.1-2.1.noarch requires python3-xdg, but this requirement cannot be provided
Problem: nothing provides libhogweed.so.5()(64bit) needed by librtmp1-2.4.20151223.fa8646d-1.53.x86_64
Solution 1: Following actions will be done:
install gstreamer-plugins-bad-orig-addon-1.18.1-4.2.i586 despite the inferior architecture
install libopenh264-6-2.1.1-1.6.i586 despite the inferior architecture
Solution 2: deinstallation of gstreamer-plugins-bad-orig-addon-1.18.0-4.2.x86_64
Solution 3: keep obsolete librtmp1-2.4.20151223.fa8646d-1.52.x86_64
Solution 4: break librtmp1-2.4.20151223.fa8646d-1.53.x86_64 by ignoring some of its dependencies
Choose from above solutions by number or skip, retry or cancel [1/2/3/4/s/r/c/d/?] (c)
Seems like the problems are still hanging around?? Any suggestions on the best way forward??
@non_space, can you please start a new thread on your issue, if you peruse the new threads there are users with the same issue… Likewise, with third party repositories you might also wish to peruse their mailing list, there is a user reporting issues as well…
Ref: https://forums.opensuse.org/showthread.php/547540-Problem-nothing-provides-libhogweed-so-5()(64bit)-needed-by-librtmp1-2-4-20151223-fa8646d-1-53-x86_
Ref: https://forums.opensuse.org/showthread.php/547548-Tumbleweed-Pacman-nothing-provides-libhogweed
Ref: [packman] [tumbleweed] update issues with libhogweed+others missing
OK, sure . . . I was just seeing this as part of the previous “mate-menu” and “python3” dependency problem that I was having in my TW installs, but perhaps this is another issue . . . seems to be a bit bumpy lately . . . .