Unfortunately, the upgrade didn't go smoothly. It booted up into a TTY on the first reboot. It looked like the nVidia driver didn't find any compatible displays so X wouldn't come up. I switched to intel (prime-select) and rebooted, but now it's showing me a "low graphics mode" dialog with options for trying full graphical mode, reconfiguring, console, etc. Dropped to a console.
MORALE OF THE STORY: SDDM was trying to start X before the nVidia driver was fully initialized, so X couldn't find any compatible displays.
SOLUTION: Use a systemd timer to delay the start of SDDM - I used 5s. See the bottom of this post.
It's trying to load the failsafe X server and I'm still getting errors!
Rebooting back into nvidia mode to diagnose logs more thoroughly.
The Xorg log shows me this error:
(EE) modeset(G0): drmSetMaster failed: Invalid argument
...
(EE) addScreen/ScreenInit failed for gpu driver 0 -1
prime-offload.log shows:
Sorry we only support randr 1.4 or higher
The Xorg failsafe log shows me nothing terribly useful.
Google gave me this:
http://askubuntu.com/questions/613021/nvidia-xorg-crashes-on-15-04-drmsetmaster-failed-invalid-argument
I ran nvidia-xconfig. Same error - no difference.
Doing an apt-get -s remove --purge nvidia-* shows me these files would be removed:
nvidia-352 [352.63-0ubuntu0.15.10.1
nvidia-opencl-icd-352
nvidia-prime [0.8.1]
nvidia-settings [352.21-0ubuntu1]
Do it.
On reinstall, it's trying to build the kernel modules for 4.4.0-rc2, which I haven't had installed in a while. Where is it finding this??
Huh, there is an initramfs file in my /boot with that version. Oops. Deleted it via update-initramfs -d -k 4.4.0-rc2+. Seemed to do something.
Let's reinstall the nvidia drivers. Gonna purge first and reinstall. Super safe...
Seemed to go smoothly, no errors. ::sigh:: Reboot.
Still no joy. Same Xorg error. Still the same, weird prime-offload error.
Manually running startx as root... display is black (no backlight). Switched to TTY2 and did 'sudo pkill X' - at least tty1 is back.
Let's prime-select to 'intel' and reboot.
Wouldn't reboot gracefully - had to use power button. Hung on the glowing Kubuntu logo.
OK, in intel mode I got the same "system is running in low graphics mode" dialog. Let's select "try running with default graphical mode".
Whoa, kde 5.5.3 came right up! Dang! With a funky new background. Yay!
Indeed, we're running on KDE 5.5.3 and Qt 5.5.1. Woo-hoo!
Moral of the story: switch to intel mode after upgrade and then figure out why nvidia's broken (again).
My old xorg.conf was:
Section "ServerLayout"
Identifier "layout"
Screen 0 "nvidia"
Inactive "intel"
EndSection
Section "Device"
Identifier "intel"
Driver "modesetting"
BusID "PCI:0@0:2:0"
Option "AccelMethod" "None"
EndSection
Section "Screen"
Identifier "intel"
Device "intel"
EndSection
Section "Device"
Identifier "nvidia"
Driver "nvidia"
BusID "PCI:1@0:0:0"
Option "ConstrainCursor" "off"
EndSection
Section "Screen"
Identifier "nvidia"
Device "nvidia"
Option "AllowEmptyInitialConfiguration" "on"
Option "IgnoreDisplayDevices" "CRT"
EndSection
I'm going to prime-select to nvidia and reboot.
Still seeing the exact same errors. Looking at journalctl -b is helpful. Here are some relevant errors:
sddm Running /usr/bin/X -nolisten tcp -auth /var/run/sddm/{...} -background none -noreset -displayfd 17 vt7
sddm running display setup script "/usr/share/sddm/scripts/Xsetup"
sddm /usr/bin/xauth bad "remove" command line
sddm /usr/bin/xauth bad "add" command line
sddm Display server stopped.
sddm Running display stop script "/usr/share/sddm/scripts/Xstop"
It then tries again with additional problems:
sddm Running /usr/bin/X -nolisten tcp -auth /var/run/sddm/{...} -background none -noreset -displayfd 17 vt7
sddm running display setup script "/usr/share/sddm/scripts/Xsetup"
sddm /usr/bin/xauth bad "remove" command line
sddm /usr/bin/xauth bad "add" command line
sddm Display server stopped.
sddm Running display stop script "/usr/share/sddm/scripts/Xstop"
sddm QProcess Destroyed while process ("/usr/lib/x86-64-linux-gnu/sddm/sddm-helper") is still running
sddm-helper Received a wrong opcode instead of AUTHENTICATED: 0
sddm.service: Main process exited, code=dumped, status=11/SEGV
sddm.service: Failed to schedule restart job: Transaction is destructive.
sddm.service: Failed with result 'resources'.
Started X.org diagnosis failsafe.
WTF?
I did get it running by manually running 'systemctl restart sddm' from the TTY. Hey, that's something!
Here's an interesting exchange about a problem similar to this:
https://bbs.archlinux.org/viewtopic.php?id=189145
As always, it's between arch users - apparently the geniuses of the Linux world.
He suggests delaying sddm by creating a systemd timer that runs after a set period. Huh. Here's what he used:
cat /etc/systemd/system/sddm.timer
[Unit]
Description=Start sddm service fixed time after boot
[Timer]
OnStartupSec=20
Unit=sddm.service
[Install]
WantedBy=multi-user.target
He then disabled sddm.service and enables the timer:
systemctl disable sddm.service
systemctl enable sddm.timer
I changed the "WantedBy" dependency to "graphical.target" instead of "multi-user" target and the delay to 5s. On my system sddm was wanted by graphical.target and not multi-user.target.
Huh, it worked. Damn!
No comments:
Post a Comment