Graphical boot fails after updating TW

Unfortunately that’s the entire Xorg.0.log I got, I can only assume that it freezes before it can get to a point where it would write the information you noted as missing in the last log.

I just tried adding a line with GRUB_CMDLINE_LINX="" to /etc/default/grub, unfortunately it made little difference: https://pastebin.com/LLGP9T1k

The live boot ran on the modesetting DDX, so focus on getting it to work first. Once everything works right using it is time enough to consider giving amdgpu another try. For now, eliminate /etc/X11/xorg.conf.d/20-amdgpu.conf if you still have it, or change its driver line to read modesetting instead of amdgpu, or comment that line. For insurance, zypper rm xf86-video-amdgpu. If there is a file /etc/X11/xorg.conf, eliminate or rename it.

If you still have all those optional repos installed, best next move might be to disable all except oss and non-oss and then zypper dup. If it works, then you can reenable needed ones one at a time to get back whatever they have that you actually need.

What version is the oldest remaining kernel installed? Does it work OK?

If you try starting X again and again get a short Xorg.0.log, do

journalctl -e

to see if you can spot a reason why X exited when it did. If you fail at spotting anything, redirect journalctl -b to a file and pastebin it and the fresh Xorg.0.log.

With amdgpu.dc=1 and nomodeset having been eliminated from cmdline it might be time to try plymouth.enable=0 again.

It’s possible the DM is a contributor, so switching between sddm and lightdm or vice versa using update-alternatives --config might help.

Here’s the Xorg.0.log after editing /etc/X11/xorg.conf.d/20-amd.conf to use the “modesetting” driver and uninstalling xf86-video-amdgpu via zypper (I checked and /etc/X11/xorg.conf doesn’t exist): https://pastebin.com/6R40dg2g
And the journalctl -b output: https://pastebin.com/nCfBVTzs

Right now the oldest installed kernel is 5.0.8-1-default, though the kernel itself doesn’t seem to be much of a factor in this issue. I also tried “sudo startx” once more for good measure and it still gives an error complaining about the missing “gbm_format_get_name”. I’ll try plymouth.enable=0 and switching display managers later on.

The just uploaded journal is from a multi-user.target boot (3 on cmdline), so of no value in troubleshooting X failure. If the just uploaded Xorg.0.log is from the same boot, I have to question why it exists, unless you used startx on this boot. Absent startx, I expect to see no fresh Xorg.0.log on multi-user boot, so very puzzling both that it exists at all, and why it’s so short. When I boot TW to the 5.0.9 kernel, the line matching your last, “ABI class: X.Org ANSI C Emulation, version 0.4”, is followed by a screenful of modeset(0) lines before any others appear. The whole Xorg.0.log is comprised of 431 lines.

Have you yet done zypper dup after disabling all optional repos?

The Xorg.0.log comes from my last attempt at a graphical boot before it froze and I hard-rebooted into multi-user mode so I could retrieve the log. I haven’t yet tried taking the Xorg.0.log immediately after running startx from a multi-user session.

That means until you can get past the freezing, Xorg.0.log will remain all but useless.

I’m not entirely sure what else to inspect in that case. So far I’ve tried adding plymouth.enable=0, switching to lightdm (both with and without plymouth.enable=0) and it had no impact. It seems to fail before it can even reach the point where the display manager is loaded. For good measure, I tried updating to 20190426 then reinstalling (via zypper in -f) every package I have installed from the X11 repo along with all Mesa-related packages. That also had no impact. The “gbm_format_get_name” error also persists when I try using startx even after all that.

I’m thinking that trying Wayland would at least be the next logical step, but (at the risk of sounding completely clueless) I’m currently having some trouble finding instructions on how to switch to using Wayland by default that don’t assume the presence of an already-working X session for changing settings from the GUI, and any instructions I have found typically tend to be for other distros on top of that. If there’s something obvious in the SDB then I may just be missing it. weston is already installed at least.

IMO the next logical step is as I suggested already 7 days ago and again on Saturday: disable all optional repos, then zypper dup. That should match you up close to the live image that worked as expected.