Wednesday, January 20, 2016

Kubuntu Wily 15.10 KDE upgrade from 5.4.3 to 5.5.3

So, Kubuntu 15.10 told me I had an update - a big update.  I'm pretty sure it's the KDE 5.5.2 that was put out last month.  Kubuntu is low on staff right now, so it takes longer for KDE releases to get repackaged.  Still, I'm thrilled that this is available.  Actually, the upgrade is to KDE 5.5.3 - amd64 4:5.5.3a-ubuntu1~ubuntu15.10~ppa5.  It looks like Qt is being upgraded to 5.5.1 - amd64 5.5.1+dfsg-1ubuntu1~wily1~test1.

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