gnome-shell[] Failed to create backend

Ps0ke · 2018-09-11 21:01:29

Hi there,
I'm having some some issues with GDM/gnome-shell/Nvidia, but I can't really figure out whats going on. After a normal reboot, my system just got stuck after opening up mu LUKS crypt without any boot messages being printed. I don't even recall having updated before or something like that. I believe it happened spontaneously.

I vaguely recall a very similar case in recent history, which was solved by switching my proprietary nvidia driver from the rolling-release to the lts version, as my graphics card rolled out of support. So I grabbed my rescue thumb drive, chroot'ed into my system and just ran a full system upgrade. After this, at least new messages appeared during boot, but the system still gets stuck at

Starting power manager..

. I also disabled all gnome extension, but that didn't help either. There also was a similar case with the dropbox.service going rampage with resulted in gnome-shell not starting, but I disabled it and the logs show none of that kind of problem.

Maybe a few words about my system:
I'm using a Lenovo T430, which features the Optimus Technology for hybrid graphics; so I have an internal Intel graphics chip and an external Nvidia GPU. Because I need the performance and couldn't setup bumblebee or primus correctly a few years back, I just disabled the intel chip and am running the Nvidia card all the time ever since. lspci says the following about my graphics card:

NVIDIA Cooperation GF108M [NVS 5400M]
    Subsystem Lenovo GF108M [NVS5400M]

The following packages match pacman -Qs nvidia

libvdpau 1.1.3+3
libxnvctrl 396.51-1
nvidia-390xx 390.77-14
nvidia-390xx-utils 390.77-1
nvidia-cg-toolkit 3.1-4

I also have the lib32 versions installed.
I also have the nouveau drivers installed, but I believe I'm using nvidia. Unfortunately switching ttys with ctrl-alt-f does not work in the non-booting state and I personally can't tell from the logs, some help to get certainty here would be well appreciated. The rescue system from the thumbdrive lists nouveau as loaded.
pacman -Qs nouveau yields

mesa 18.1.8-1

plus the lib32 version.

Seeing this I added

nvidia-drm.modeset=1

to my

/usr/modprobe.d/nvidia-390xx.conf

, but that didn't change anything. Previously the file only contained the nouveau blacklist.

I also tried reinstalling the nvidia driver--to no effect. I also tried removing the nouveau blacklist entry in the nvidia modprobe config and added some xorg configuration according to the wiki to test if the nouveau driver was working. Now the system keeps creating more c2, c2, c3, ... sessions for gdm and keeps crashing.

I'm really clueless at this point. I don't know graphics card stuff, x, gdm enough to be able to debug it or find further information. Also I can only inspect the system from the rescue thumb drive, so I'm not even entirely sure which drivers are loaded etc. All I can do is look at the logs. If you have any hints, that would be great!

Here is some excerpt from my last boot log (I can't easily post everything, since I can only look at the logs using the cli-only rescue disk and have to manually copy everything here using my roommates computer. )

...
systemd: Started Daemon for power management.
gnome-shell: Failed to create backend: Could not find a primary drm kms device
gnome-session-binary: Unrecoverable failure in required component org.gnome.Shell.desktop
gnome-session-binary: WARNING: App 'org.gnome.Shell.desktop' exited with code 1
gdm: GdmDisplay: display lasted 1,08569 seconds
systemd-logind: Session c1 logged out. Waiting for process to exit
systemd-logind: Removed session c1
gdm: Child process -516 was already dead
gdm: Child process 439 was already dead
gdm: Unable to kill session worker process
...
/usr/lib/gdm-x-session: <config yadayada>
/usr/lib/gdm-x-session: Load Module  nvidia
/usr/lib/gdm-x-session: Loading /usr/lib/xorg/modules/drivers/nidia_drv.so
...
/usr/lib/gdm-x-session: Fatal server error:
/usr/lib/gdm-x-session: (EE) no screens found(EE)
...

this repeats a couple of times with the c1 user number increasing.
I hope this helps, if you need me to copy more gdm-x-session output, or some other parts of the log, please let me know. In the meantime I'll look into a possibility to copy the logfile to somewhere wehre I can easily paste it. Same is true for the /var/log/Xorg.0.log file, which might be useful?

Thanks so much!

Edit:
I managed to mount another thumb drive and copy the logs. Could've thought about that earlier.
This is journalctl -e > journal.log. For some reason -b -0 just gives me an empty less and -b -1 the second-to-last boot. So I resided to this method. Maybe be so kind and teach me how to properly use and export with journalctl.
This is /var/log/Xorg.0.log.

Last edited by Ps0ke (2018-09-11 21:23:44)

loqs · 2018-09-11 22:08:00

Current Operating System: Linux rechenschieber 4.17.9-1-ARCH #1 SMP PREEMPT Sun Jul 22 20:23:36 UTC 2018 x86_64

Both the kernel version and the time seem wrong for that being the current issue. The issue shown in the logs posted was the absence of the nvidia kernel module but that log is from six weeks ago.

Ps0ke · 2018-09-12 01:17:42

loqs wrote:

Current Operating System: Linux rechenschieber 4.17.9-1-ARCH #1 SMP PREEMPT Sun Jul 22 20:23:36 UTC 2018 x86_64
Both the kernel version and the time seem wrong for that being the current issue. The issue shown in the logs posted was the absence of the nvidia kernel module but that log is from six weeks ago.

What is wrong with my method of retrieval? I believe

journalctl -e

should give me the full log—hence the

-- Logs begin at Sat 2014-06-14 19:36:36 CEST, end at Wed 2018-09-12 00:10:49 CEST. --

—
scroll to the end (`-e`) and by default trunkate to 1000 lines. The timestamp of the logs

Sep 12 00:08:34 rechenschieber kernel:

shows today's date. Because I booted Windows in the meantime the BIOS time was set to a different time zone convention as Linuxes'. The log lines are printed before the NTP could update the system clock. Because of my time zone and DST the timestamp is off by two hours. I'm sorry I forgot this detail.

The Xorg logs were obtained by copying the file from within a chroot into my system from the specified location to a thumb drive using `cp`. I can't see any timestamps here.

I don't know why the kernel version is wrong, I updated and rebooted my system before posting here for over two hours using `pacman -Syuu`. I'm pretty sure I'm on the forefront of the rolling release.

Concerning the Nvidia driver: It could be that the settings for the nouveau drivers were unsuccessful, maybe the nvidia config file is not read properly and the black listing still enabled? I could also have confused the order of events and what I did. I tried multiple things as listed and could've ended up in Nvidia state as well.

But I still think this is the correct log, so I'm currently in this state. What should I try next? :)

Edit:
Fixed the typo `-Yuu` to -`Syuu` for clarity.

Last edited by Ps0ke (2018-09-12 07:51:46)

jasonwryan · 2018-09-12 01:22:51

Ps0ke wrote:

I updated and rebooted my system before posting here for over two hours using `pacman -Yuu`.

That's not an update. What is the output of `pacman -Q linux && uname -a`?

Ps0ke · 2018-09-12 08:05:29

jasonwryan wrote:

Ps0ke wrote:
I updated and rebooted my system before posting here for over two hours using `pacman -Yuu`.

That's not an update. What is the output of `pacman -Q linux && uname -a`?

Sorry that was my bad. I meant to say `-Syuu`. So I did a full upgrade, also ran it again just now just in case. I'm sorry this support request is such a mess…

# pacman -Q linux 
linux 4.18.6.arch1-1
# uname -a
Linux archiso 4.9.6-1-ARCH #1 SMP PREEMPT Thu Jan 26 09:22:26 CET 2017 x86_64 GNU/Linux

I believe the uname output is not correct, since I can only run it from the rescue thumb drive and not with the actual problematic OS. It's output should be the rescue system's, not my actual one. Also the output is identical in and out of the chroot. Running `pacman -Q linux` outside the chroot gives me `linux 4.9.6-1` for the rescue system, which matches the `uname` output.

How can I get the `uname` output for my actual system if I don't have access to a shell, since the boot is hanging and switching ttys with ctrl+alt+fx is not working? I don't think I have SSH remote login enabled and don't have a second computer to try.

jasonwryan · 2018-09-12 08:19:03

The output is what it is. You need to ensure that youdo a full update with your /boot mounted so that the outputs do match. The fact that it is reporting such an ancient kernel suggests that something is seriously wrong, or there is something about your setup that you are neglecting to mention.

V1del · 2018-09-12 08:54:11

@jason that's the iso kernel that's that outdated

@Ps0ke Boot into systemd.unit=multi-user.target on your kernel parameters. That should boot you to a console to share the other relevant outputs. However as already mentioned, it is likely that you didn't have your /boot partition mounted when doing the full upgrade. You might also want to share your pacman.log so we get a bit of an overview over what got updated exactly.

Last edited by V1del (2018-09-12 08:56:43)

Ps0ke · 2018-09-12 09:26:27

jasonwryan wrote:

The output is what it is. You need to ensure that youdo a full update with your /boot mounted so that the outputs do match. The fact that it is reporting such an ancient kernel suggests that something is seriously wrong, or there is something about your setup that you are neglecting to mention.

Judging from these two posts, I believe the `uname` will always report the kernel version of the running system, not the chroot. Same goes for `/proc`. I also grabbed a full log now. Weirdly enough, `journalctl --list-boots still ommits the latest one, `journalctl -b -0` gives me an empty log and `journalctl -b -1` the second to last one. But I increased the truncation limit and retrieved a full boot log of the last boot using `journalctl -e -n 1700`. The kernel is shown to be

Sep 12 12:41:56 rechenschieber kernel: Linux version 4.17.9-1-ARCH (builduser@heftig-26261) (gcc version 8.1.1 20180531 (GCC)) #1 SMP PREEMPT Sun Jul 22 20:23:36 UTC 2018

While this is not as ridiculously old as the live image, guessing from the current `linux` package version, `linux 4.18.6.arch1-1` it is still out of date.

V1del wrote:

@jason that's the iso kernel that's that outdated
@Ps0ke Boot into systemd.unit=multi-user.target on your kernel parameters. That should boot you to a console to share the other relevant outputs. However as already mentioned, it is likely that you didn't have your /boot partition mounted when doing the full upgrade. You might also want to share your pacman.log so we get a bit of an overview over what got updated exactly.

I added systemd.uni=multi-user.target to the kernel parameters using grub during boot. It gets stuck at the same point in the output messages.I also took a picture of the on-screen messages during the boot, so you can see where it hangs. I also grabbed the latest boot log with these settings using the same `journalctl` command as above.

This is some of my recent pacman.log

Thanks so much for the help so far!

loqs · 2018-09-12 09:32:02

systemd.uni=multi-user.target is not systemd.unit=multi-user.target

V1del · 2018-09-12 09:38:06

Yeah all of that is pretty tell tale of an outdated kernel with not intended for rest of the stack. Chroot in from the live session, ensure that your /boot partition is mounted and reinstall the linux package.

Ps0ke · 2018-09-12 14:47:18

V1del wrote:

Yeah all of that is pretty tell tale of an outdated kernel with not intended for rest of the stack. Chroot in from the live session, ensure that your /boot partition is mounted and reinstall the linux package.

Okay that really was my bad. Mounting the `/boot` before upgrade did the trick. I wrote that down on the sticky note on the rescue thumb drive

For sake of clarity: I firgured out which partition my boot is on with `lsblk` and then mountet it to `<chroot root mountpoint>/boot`. In total

cryptsetup open /dev/sda2 main
mkdir root
mount /dev/main root root
mount /dev/sda1 root/boot
arch-chroot root
pacman -S linux
pacman -Syuu

Now my system started as usual. Since it was still configured to run nouveau, the kernel mode setting even worked and I got nicely rendered boot log output. But when I re-added the nouveau blacklisting in the nvidia config and removed the noveau Xorg config file, I got the same error! I even reinstalled the nvidia drivers and the linux package to make sure all hooks were run etc, but it didn't help. I'm good for now, but I think in general I want to run the Nvidia drivers, in the hopes to get Nvidia Optimus to work at some point eventually. Any hints whats going wrong with Nvidia? Before this whole odyssey I was running Nvidia for 4 years straight with no problems (other the described hickup when my card was moved to legacy).

V1del · 2018-09-12 14:53:04

Because I haven't seen it explicitly mentioned yet, the remaining issue is likely attributable to GDM trying and failing to initialize the Wayland backend, so make sure to disable that

If that wasn't it please post an update

journalctl -b

from a failing boot and a xorg.log

Arch Linux

#1 2018-09-11 21:01:29

gnome-shell[] Failed to create backend

#2 2018-09-11 22:08:00

Re: gnome-shell[] Failed to create backend

#3 2018-09-12 01:17:42

Re: gnome-shell[] Failed to create backend

#4 2018-09-12 01:22:51

Re: gnome-shell[] Failed to create backend

#5 2018-09-12 08:05:29

Re: gnome-shell[] Failed to create backend

#6 2018-09-12 08:19:03

Re: gnome-shell[] Failed to create backend

#7 2018-09-12 08:54:11

Re: gnome-shell[] Failed to create backend

#8 2018-09-12 09:26:27

Re: gnome-shell[] Failed to create backend

#9 2018-09-12 09:32:02

Re: gnome-shell[] Failed to create backend

#10 2018-09-12 09:38:06

Re: gnome-shell[] Failed to create backend

#11 2018-09-12 14:47:18

Re: gnome-shell[] Failed to create backend

#12 2018-09-12 14:53:04

Re: gnome-shell[] Failed to create backend

Board footer