Long-running login/session problem

BentAxl · August 16, 2026, 5:09pm

Hiya,

I’m looking for help diagnosing a long-running login/session problem on a fresh-ish openSUSE Leap 16.0 installation.

I have limited Linux knowledge, so I’m trying to be very careful about making changes. I have previously gotten this machine into a state bad enough that I had to reinstall Leap 16.0, so I would prefer to diagnose first and change things second.

Hardware / system
OS: openSUSE Leap 16.0
Computer: Dell OptiPlex 7040
CPU: Intel Core i7-6700
RAM: 32 GB
GPU: Intel HD Graphics 530
GPU driver: i915
Display: HDMI, 1280×1024
Desktop currently: GNOME 48.4
Display manager currently: GDM
Display protocol: Wayland/Xwayland
Mesa: 24.3.3
Kernel examples: 6.12.0-160000.x-default

The graphics information consistently reports:

Intel HD Graphics 530
driver: i915
Mesa Intel HD Graphics 530 (SKL GT2)
Wayland
Xwayland
gnome-shell 48.4

There is one particular piece of hardware history that may or may not be relevant: I remember an earlier troubleshooting session involving the Intel HD Graphics 530 and a number 530, and I believe I may also have performed a kernel-related update from USB around that period. I don’t yet know whether either is relevant.

There appear to be TWO login problems

This is an important distinction.

Problem #1 — longstanding desktop-switching problem

Since relatively early after installing Leap 16.0, I have been unable to successfully switch between desktop environments.

I tried GNOME, Plasma and other desktops. When I logged out and attempted to select another desktop, the login screen would quiver/flicker rather than behaving normally, and I could not proceed normally.

I believe this problem existed before the more recent autologin problem described below.

I originally installed Leap with autologin enabled, and the computer would automatically enter GNOME.

Problem #2 — later autologin/login problem

Much later, during troubleshooting, autologin was deliberately turned off through the settings in order to test something.

That changed the machine from:

boot → automatically enter GNOME

to:

boot → login screen

The resulting login screen now exhibits the same/similar quivering behavior, and I have not been able to get back to the original clean autologin behavior.

The important point is that I don’t currently know whether turning off autologin caused a new problem or merely exposed the older login/session problem that had previously been hidden by autologin.

I am currently running from Snapper rollback 282 because that is a usable state for me.

Snapper history

I have a large Snapper history and am trying to use it as evidence rather than continuing to make random changes.

There appears to be an interesting period around snapshots 143–149.

For example:

produced significant changes involving:

/etc/gdm/custom.conf
/etc/gdm/custom.conf.save
/etc/sysconfig/displaymanager
/etc/sddm.conf.d/numlock.conf

/usr/sbin/gdm
/usr/libexec/gdm/gdm-session-worker
/usr/libexec/gdm/gdm-wayland-session
/usr/libexec/gdm/gdm-runtime-config

/usr/share/wayland-sessions/labwc.desktop
/usr/share/wayland-sessions/xfce-wayland.desktop
/usr/share/xsessions/gnome.desktop
/usr/share/xsessions/gnome-xorg.desktop
/usr/share/xsessions/xfce.desktop

There were also PAM-related changes and a large number of kernel files.

The transition includes kernel versions such as:

6.12.0-160000.25
6.12.0-160000.26
…
6.12.0-160000.36

There were also additions associated with XFCE and other desktop/session components.

Interestingly, the immediately preceding filtered comparisons such as:

145…146
146…147
147…148

did not produce meaningful matches for the login/session search terms.

So 148→149 currently stands out much more than those individual transitions.

Graphics information

My graphics configuration has been remarkably consistent in the information I have collected.

For example:

Device-1: Intel HD Graphics 530
driver: i915
chip-ID: 8086:1912

Display: wayland
server: X.org
Xwayland
compositor: gnome-shell
driver: modesetting
gpu: i915

OpenGL:
Mesa Intel HD Graphics 530 (SKL GT2)

EGL:
iris

The monitor is connected through HDMI and is reported as 1280×1024.

I don’t know whether this points toward a graphics problem or is simply normal for this hardware.

Mesa / Qt

At one point I checked the installed Mesa and Qt graphics packages.

Installed Mesa packages included:

Mesa-24.3.3-160000.2.2
Mesa-dri-24.3.3-160000.2.2
Mesa-libEGL1-24.3.3-160000.2.2
Mesa-libGL1-24.3.3-160000.2.2
Mesa-gallium-24.3.3-160000.2.2
Mesa-libglapi0-24.3.3-160000.2.2
Mesa-libva-24.3.3-160000.2.2

Qt packages included:

libQt6Gui6-6.9.1-160000.2.2
libQt6OpenGL6-6.9.1-160000.2.2

At one point I was instructed to force-reinstall several of these packages. The four packages that actually reinstalled successfully were:

Mesa-dri
Mesa-libGL1
Mesa-libEGL1
libQt6Gui6

The command also contained an incomplete libQt6Open… package name, which was not found. The transaction completed the four valid reinstallations but reported an error because of that invalid package name.

I don’t know whether that had any relationship to the login problem.

Current repository situation

My enabled repositories include the normal Leap OSS repository as well as several additional repositories, including Packman, Mozilla, games/tools, Brave, NordVPN, etc.

I am mentioning this because I don’t want to assume everything on the system necessarily came from the standard Leap repositories.

What I am trying to determine

At this point I’m trying to answer a fairly basic question:

Where should I be looking?

Does this history look more like:

a GDM/login configuration problem,
PAM/session configuration,
multiple desktop environments/display managers having been installed and interacting,
an Intel HD 530 / graphics stack problem,
a kernel/graphics change,
something related to the original autologin configuration,
or some combination of these?

And, importantly:

Is the Snapper history around 143–149 worth investigating further to find when the original problem was introduced?

I also have the much later Snapper history around 282, where troubleshooting specifically involved turning off autologin.

I am currently rolled back to 282 and the machine is usable, so I would strongly prefer not to make irreversible changes or start uninstalling/reinstalling display managers until there is some understanding of what the evidence says.

I have additional inxi output and Snapper comparisons if they would be useful.

I’m primarily looking for interpretation/diagnosis at this stage, rather than a list of commands to try. Any advice is helpful.

Thank you.

jonzn4suse · August 16, 2026, 7:28pm

See if this helps.
https://www.freedesktop.org/software/systemd/man/latest/systemd-analyze.html

Here are a few results from my laptop.

jonzn4suse · August 16, 2026, 7:37pm

Old post with helpful info.

BentAxl · August 29, 2026, 1:06pm

Follow-up: SDDM/GNOME login quiver fixed by restoring the vendor PAM configuration

I wanted to post a follow-up to my earlier Leap 16.0 login/session problem because I believe I have finally identified the cause of the long-standing manual-login failure.

The original problem

On my Dell OptiPlex 7040 running openSUSE Leap 16.0, automatic login into GNOME Wayland worked normally.

However, when I logged out and tried to log back in manually through SDDM:

GNOME desktop
→ Log Out
→ SDDM login screen
→ enter correct password
→ screen quiver/flicker
→ GNOME session failed to start

The problem had been present since the original Leap 16 installation and persisted across many Snapper snapshots, so I initially suspected graphics, Wayland, SDDM, PAM, or some combination of those.

What I eventually found

The active /etc/pam.d/sddm contained only:

session optional pam_gnome_keyring.so auto_start

That was very different from the vendor SDDM PAM configuration.

For the test, I did not modify my known-good recovery snapshot. I created a writable Snapper clone and changed the PAM file only in that clone.

I backed up the original file first, then replaced:

/etc/pam.d/sddm

with the vendor copy:

/usr/lib/pam.d/sddm

I verified the two files were byte-for-byte identical.

The result

The manual login problem immediately changed:

Log Out
→ SDDM
→ enter correct password
→ GNOME desktop

No failed session and no original login quiver.

I repeated the test and it continued to work.

I also rebooted the system and repeated the manual login test again. It still worked.

Update/reboot test

After that, I installed the pending Leap 16 updates.

The update included a new kernel and a newer Brave release. After reboot:

kernel: 6.12.0-160000.37-default
Brave: 152.1.94.117

I performed another:

Log Out
→ SDDM
→ correct password
→ GNOME

and the login still worked normally.

Current conclusion

I am not claiming that this proves the same issue will occur on every Leap 16 installation, but on my machine the evidence strongly points to the local /etc/pam.d/sddm override as the cause of the long-standing manual-login problem.

The important part for me was the controlled comparison:

Before:

/etc/pam.d/sddm
session optional pam_gnome_keyring.so auto_start

→ manual SDDM login failed/quivered.

After:

/etc/pam.d/sddm
= /usr/lib/pam.d/sddm

→ manual SDDM login succeeds.

The fix also survived reboot and the subsequent Leap 16 updates.

System details

openSUSE Leap 16.0
Dell OptiPlex 7040
Intel HD Graphics 530 / i915
GNOME Wayland
SDDM
SDDM package: sddm-qt6-0.21.0-lp160.4.1.x86_64

I am posting this in case it helps anyone else who has the unusual combination of GNOME + SDDM + a successful autologin path but a failing interactive login path.

Thanks to everyone who contributed suggestions to the original discussion.

This wording keeps the strongest evidence—the controlled A/B test—front and center while avoiding the stronger claim that the PAM file is universally the root cause.

BentAxl · August 29, 2026, 1:09pm