SDDM black login screen with mouse pointer

This is a continuation of a previous topic:

I do get the exact same symptoms but the suggested workarounds do not work for me (i.e. adding kernel parameters). As this is my main system, I had to roll back (I am still on 20240321), I do not have logs available.
I did inspect the systemd journal and it appears that SDDM fails to be able to use open(E)GL. As a result, SDDM crashes. I am on amd hardware (ryzen 5700u) and I have checked corresponding packages. Mesa packages are not installed due to conflicts with wayland packages. Forcing those packages does not change the result. I do not use wayland, so I would be fine removing wayland packages in favor of X11 packages.

Thank you very much in advance.

Do you mean that Mesa is not being upgraded?
What repositories do you have configured?
Looks like you are facing some package conflicts.

Some Mesa packages had conflicts with wayland packages when doing the zypper dup

Here are my repos.

#  | Alias                            | Name          | Enabled | GPG Check | Refresh
 1 | Education                        | Education     | Yes     | (r ) Yes  | Yes
 2 | amdgpu                           | amdgpu        | Yes     | (r ) Yes  | Yes
 3 |    | Main Reposi-> | Yes     | (r ) Yes  | Yes
 4 |        | Main Reposi-> | Yes     | (r ) Yes  | Yes
 5 | | Main Update-> | Yes     | (r ) Yes  | Yes
 6 | games                            | games         | Yes     | (r ) Yes  | Yes
 7 | libdvdcss                        | libdvdcss     | Yes     | (r ) Yes  | Yes
 8 | microsoft-edge                   | microsoft-e-> | Yes     | (r ) Yes  | Yes
 9 | packman                          | packman       | Yes     | (r ) Yes  | Yes
10 | repo-debug                       | openSUSE-Tu-> | No      | ----      | ----
11 | repo-openh264                    | Open H.264 -> | Yes     | (r ) Yes  | Yes
12 | repo-source                      | openSUSE-Tu-> | No      | ----      | ----
13 | rocm                             | rocm          | No      | ----      | ----
14 | science                          | Software fo-> | Yes     | (r ) Yes  | Yes
15 | server_mail                      | Email servi-> | Yes     | (r ) Yes  | Yes

I just realized that there are a bunch of Mesa packages from the amdgpu repo which are not installed

   | mesa-amdgpu-dri-drivers                   | Mesa-based DRI drivers  | package
   | mesa-amdgpu-filesystem                    | Mesa driver filesystem  | package
   | mesa-amdgpu-libEGL                        | Mesa libEGL runtime l-> | package
   | mesa-amdgpu-libEGL-devel                  | Mesa libEGL developme-> | package
   | mesa-amdgpu-libgbm                        | Mesa gbm library        | package
   | mesa-amdgpu-libgbm-devel                  | Mesa libgbm developme-> | package
   | mesa-amdgpu-libGL                         | Mesa libGL runtime li-> | package
   | mesa-amdgpu-libGL-devel                   | Mesa libGL developmen-> | package
   | mesa-amdgpu-libglapi                      | Mesa shared glapi       | package
   | mesa-amdgpu-libxatracker                  | Mesa XA state tracker   | package
   | mesa-amdgpu-libxatracker-devel            | Mesa XA state tracker-> | package
   | mesa-amdgpu-vdpau-drivers                 | Mesa-based DRI drivers  | package

I am wondering whether I should install those. At the moment the system works fine without those packages.

I tried to lock the Mesa package (probably a meta-package) before doing the zypper dup as suggested in a similar thread. However, by now, too many conflicts arose and I decided to abort the upgrade.

@sboehringer there is no support for the amdgpu proprietary drivers, they are all for the Leaps/SLE versions… if you looking at using them, there are some Forum threads about using distrobox instead…

1 Like

Instead of writing “here are my”, always, always, always, always paste what you see on your screen:

  1. the command!!!,
  2. the command’s output,
  3. the empty shell prompt that indicates the previous line contained the last of the command output.

If you redirected to a file that only contains the output without the command, type in the command, so that we can see what you did rather than what you think is important.

A list of repos in a help request context is virtually useless by default. Either edit /etc/zypp/zypper.conf to change the default output to include URLs, or append the -u switch to the command every time you use it, so that the most important part of available output is actually output - the URL. My /etc/zypp/zypper.conf contains repoListColumns = au which causes:

# zypper lr
#  | Alias        | Enabled | GPG Check | URI
 1 | FCL-leap     | Yes     | ( p) Yes  |
 2 | KDE3         | Yes     | (r ) Yes  |
 3 | Libdvdcss    | Yes     | (r ) Yes  |
 4 | NonOSS       | Yes     | (r ) Yes  |
 5 | OSS          | Yes     | (r ) Yes  |
 6 | Update       | Yes     | (r ) Yes  |
 7 | UpdateBP     | Yes     | (r ) Yes  |
 8 | UpdateNonOSS | Yes     | (r ) Yes  |
 9 | UpdateSLE    | Yes     | (r ) Yes  |
10 | openh264     | Yes     | (r ) Yes  |

Share your repos correctly, and possibly someone can offer useful suggestions to solve your problem. It looks to me offhand you may be a 1-click user, a bad habit to have, as 1-clicks usually add repos without disabling them after installation of whatever they installed. Keeping non-standard repos enabled eventually, if not sooner, causes repo conflicts, and breaks things.

You may be able to resolve all conflicts by simply disabling all non-standard repos to do your dup, and thinking logically about the resulting questions posed before answering.

Why so many repositories?
The more repositories the more headaches you get.

Report this: zypper repos --details

Let only these three repositories enabled:

Let repo-openh264 enabled too if it is equals to

Then run: > LANG=C; TMPFILE=$(mktemp /tmp/zypper-XXXXX) && sudo zypper dist-upgrade --allow-vendor-change --details --auto-agree-with-licenses | tee ${TMPFILE}; cp -vi ${TMPFILE} ${HOME}

In case of error with the upgrading you will have a file named zypper-* in your home.


Thank you. When installing the mesa-*amdgpu* the system comes up again, although with an sddm fallback as seems to be missing for the sddm-greeter-qt6 theme. I couldn’t coax the system creating soft links from the installed This should error should be unrelated to the missing openGL context seen for the radeon driver. Unfortunately, I still cannot login as I now get a black screen after login.

The reason for the repos is that they contain software I use.

The upgrade did not produce any errors and went smoothly. Only, did I try to lock the current Mesa-* packages to prevent pulling in the bug. This did not work, as too many conflicts arose. I would not be able to perform the upgrade without breaking quite some packages.

I believe that the work around suggested in the above post, only works on SLE where amdgpu is supported. It seems I have to wait for the Mesa fix before upgrading again.

If you don’t follow the instructions neither show the conflicts you are facing, there is not much one can do.

The problem is fixed as of tumbleweed release 20240701.

sudo zypper dup --allow-vendor-change --details --auto-agree-with-licenses

with the packman repository enabled fixed the problem. Thanks everyone.

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