Ubuntu 20.04 crashes WHILE on login screen, after 5 seconds

Hi.

I was working at my computer today when it froze up. I did a reboot, and now when I boot up, I get the login screen for 5 seconds, and it’s fully responsive. I can get my password typed in and everything. But after 5 seconds, it crashes to a black screen with a blinking white cursor in the upper left. I can’t do anything on this window. However, I CAN switch over to a TTY terminal. I’ve tried things like reinstalling GDM but I’m not making any headway. My GPU is an AMD RX580; been seeing lots of people mentioning Nvidia GPU issues but I’m not having any of that.

Any other advice?

during the time of the crash could you open a separate TTY like you stated and look for errors presented by dmesg?

Okay, I booted the computer, then went over to TTY3 (CTRL ALT F3) and logged into that. I ran dmesg and the last message was timestamped 18.960892.

Then I went back over to the login screen (CTRL ALT F1) and started typing my password and saw the crash as expected.

Then after it crashed to that black screen I went back to my TTY3 and ran dmesg again. The only new timestamps after the 18.960892 were “rfkill: input handler disabled” and then “rfkill: input handler enabled”

Note that I can do CTRL ALT F1 as many times as I like and get the login screen back, over and over, even after it crashes.

If I’m very very fast I can get my whole password punched in, and then it loads up my desktop which shows the background and starts the “grow to fill screen” animation, but then freezes entirely and I am unable to go into TTY

On a tty, you might try

journalctl -r

In case systemD has any info about what crashed?
There is probably something in /bar/log or something, but I’m not a Linux ninja

That does appear to show a whole bunch of information, yes.

I made it crash and then grabbed the first 300 lines. Here’s that dump:

web(dot)mit(dot)edu/tjmurphy/www/mydump.txt

I bumped your trust level so you should be able to post links now

Great, thanks!

http://web.mit.edu/tjmurphy/www/mydump.txt

That’s the one. Lucky I’m able to upload files via SSH :slight_smile:

Okay, so I looked at that file and noticed near the top it says “Segmentation fault” a couple times, and below that is a stacktrace listing Xwayland a few times.

I then found this: https://unix.stackexchange.com/questions/460041/xwayland-crashes-frequently

and following the instructions, disabled Wayland. My computer now appears to function perfectly.

I’d like to find a long-term solution though - how do I fix Wayland so I don’t have to disable it? It’s great to now have a workaround to not rely on it, but I’d like to have my computer fully functioning as before.

1 Like

Looking at the log, it the bit you noticed with the “seg fault,” it appears the responsible apps are the AMD driver and Wayland, or the xwayland compatibility part.

It might be as simple as waiting for an newer version of the AMD drivers to come out, and that might “just work” with wayland your combination of hardware.
Or simply removing and re-installing the AMD driver might do it. (or wayland, as it;s currently disabled anyway?)

I’m just spitballing here, and the short term solution sounds right; Canonical wanted to go Wayland a while ago, but these kind of show stoppers still crop up.

What kernel are you using and did you ever install the Proprietary AMD Driver?
That GPU has been pretty stable since the 5.4 Kernel. You should have no issues with Wayland and X wayland, unless you have stuff in your xorg config file.

**Edit
Also make sure you are running the recent AMD Firmware and latest Mesa available.

1 Like

My kernel version, according to uname -srm, is Linux 5.4.0-48-generic x86_64

I’ve always used amdgpu-pro.

Not familiar with AMD Firmware or Mesa. Happy to provide those diagnostics if you let me know what’s needed.

Have you tried blacklisting the radeon drivers since you are using the pro?

sudo mcedit /etc/default/grub

add this at the end:

blacklist radeon

also add on new lines:

GRUB_GFXMODE=1920x1080x32
GRUB_CMDLINE_LINUX_DEFAULT="radeon.si_support=0 radeon.cik_support=0 amdgpu.si_support=1 amdgpu.cik_support=1 amdgpu.dc=1 amdgpu.dpm=1 amdgpu.modeset=1"

After that update grub:

sudo update-grub2 && sudo update-initramfs -u -k all<br> sudo reboot

There is info about having both drivers enabled causing problems here:

https://wiki.archlinux.org/index.php/Talk:AMDGPU

A guy had some detailed info on how to blacklist drivers etc here:

https://randomblog.hu/setting-up-your-amd-video-card-in-ubuntu-20-04/

Unless you need GPGPU support with no hassle, AMD recommends that you use the opensource driver (built into the kernel) instead of installing the Proprietary driver.

You can still run part of the proprietary driver as a hybrid stack if you prefer the Pro compute stuff (OpenCL, ROCm, and what not). The command line arguments that @jdfthetech mentioned will force the AMDGPU open source driver to load, but really you do not need that since your card does not work with the radeon driver (was never supported) so the opensource driver will load if you uninstall the proprietary.

I suggested that because he is using AMDGPU-PRO

amdgpu kernel option is for the opensource stuff, not the pro driver. AMD has not been very good at naming their stuff.