I recently decided to move my home pc’s not so used Linux from Debian Wheezy to Debian Stretch. To give it a try and help with testing Stretch before actual release, Stretch has been frozen for few months now and should be released later this year.

The Upgrade went smoothly from Wheezy->Jessie->Stretch. So now i was running Debian Stretch with new KDE5 Plasma desktop with proprietary nvidia drivers. I’m running multi user setup, where every family member has his/her own user to use the pc. To my surprise I got call from other user that there is error message on screen to continue run “loginctl unlock-sessions”.

One of the perks/tradeoffs of running Debian is that usualy other distros have already had the problems you are running into if they arent Debian specific.

At first glance it seemed like systemd related problem, after some googling I found something similar related to kde, actualy there was several posts from 2015/2016 related to kscreenlocker and systemd issues that broke lockscreen, but my problem seemed a bit different because locking/delocking itself was working okey, but the problem would appear when users were switched.

So I continued searching for bug report that would be more similar to mine, after some more effort i managed to find bugreport what matches my description. Being relatively recent and offering some more hints into the problem (comments mention that the problem only affects machines with nvidia proprietary drivers). Besides giving more data to figure out the problem it showed that I’m not alone and the same problem is affecting people on different distros so it isn’t Debian Specific. Sadly the bug report didnot offer actual solution for me.

So i decided to go back and search for more kde5 related issues and solutions and found this thread what stood out was message “Also don’t forget to update your Intel CPU microcode”, as of i hadn’t knowingly updated my cpu microcode i decided to check what version im running and give it a try.

This PC has actualy fairly recent cpu:

root@home:~# grep "model name" /proc/cpuinfo  | head -n1
model name      : Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz

To figure out what microcode cpu is running, dmesg comes to rescue

root@home:~#  dmesg | grep 'microcode'
kernel: [    1.063689] microcode: sig=0x306c3, pf=0x2, revision=0x17

After finding the microcode im running from intel-microcode package changelog I figured that I’m running cpu microcode from 2014, most likely the same version it came from factory. Debian can upgrade your cpu microcode simply by installing apropriate package and rebooting (the microcode will be updated at boot time).

root@home:~#  apt-get install intel-microcode

After reboot dmesg shows something new:

root@home:~#  dmesg | grep 'microcode'
[    0.000000] microcode: microcode updated early to revision 0x20, date = 2016-03-16
[    1.063617] microcode: sig=0x306c3, pf=0x2, revision=0x20
[    1.063964] microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>, Peter Oruba

Now that I was running latest microcode I gave the user switching another try and VOILA it is working as intended. Lesson learned the hard way: if you run into “strange” problems with your Linux, make sure you are running the latest microcode available for your cpu.