I recently upgraded my 3-year-old Lenovo X1 Carbon from Ubuntu 16.04 TLS to 18.04 LTS. I think I ran into the two most common upgrade issues, and since both of them are show-stoppers, I thought it would be worth sharing the resolutions that worked for me.
Here are the two problems:
- "Login Loop": After a valid authentication on the login screen, the display goes black momentarily, and then returns you to the login screen.
- systemd-udevd CPU usage: On my system, it consumed about 20% of the CPU. I've read that it can be much higher on other systems (like 100%).
The Upgrade
Simple: From Software & Updates on the Updates tab, select 'For any new version':
After the next update, the Software Updater will offer the 18.04 upgrade option.
Just click on the Upgrade... button and follow the instructions from there.
Login Loop
After the upgrade is complete, this problem will prevent you from logging in to a Gnome desktop. Use Alt-Ctrl-F2 to drop to a terminal and login. Execute the following:
|
1 2 3 4 |
$ sudo apt-get purge gdm* $ sudo apt-get purge lightdm $ sudo apt-get install lightdm $ sudo apt-get install nvidia-352 |
Just removing gdm and re-installing lightdm was not sufficient to resolve this issue for me. Installation of the Nvidia driver (line 4) was the key. Later versions than nvidia-352 (like nvidia-384) will also probably work.
systemd-udevd CPU Usage
Now that you can login to your desktop, you may notice high CPU usage. If top or htop show that systemd-udevd is the culprit, confirm that UDEV events are being generated with udevadm. For me the output looked like this:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
$ udevadm monitor monitor will print the received events for: UDEV - the event which udev sends out after rule processing KERNEL - the kernel uevent KERNEL[33.704228] add /module/nvidia (module) KERNEL[33.704784] add /kernel/slab/:0012288 (slab) KERNEL[33.705062] remove /kernel/slab/:0012288 (slab) UDEV [33.705332] add /kernel/slab/:0012288 (slab) UDEV [33.705659] remove /kernel/slab/:0012288 (slab) KERNEL[33.724214] remove /module/nvidia (module) KERNEL[33.755768] add /module/nvidia (module) KERNEL[33.756482] add /kernel/slab/:0012288 (slab) KERNEL[33.756764] remove /kernel/slab/:0012288 (slab) UDEV [33.757642] add /kernel/slab/:0012288 (slab) UDEV [33.757981] remove /kernel/slab/:0012288 (slab) KERNEL[33.772269] remove /module/nvidia (module) UDEV [33.792191] add /module/nvidia (module) UDEV [33.807097] remove /module/nvidia (module) KERNEL[33.830290] add /module/nvidia (module) ... |
This can be resolved by stopping the systemd-udevd service:
|
1 |
$ sudo systemctl stop systemd-udevd systemd-udevd-control.socket systemd-udevd-kernel.socket |
The CPU usage will drop and udevadm stops reporting events.
If needed, the systemd-udevd service can be started again:
|
1 |
$ sudo systemctl start systemd-udevd systemd-udevd-control.socket systemd-udevd-kernel.socket |
I found that the CPU issue did not re-appear after the service was restarted.
Startup Changes
This is great, but you don't want to have to manually run a command every time you log into your system. Here is how to execute this command automatically at startup.
First, you need to be able to execute the systemctl command as root without having to enter a password.
Create a script and set the correct permissions as follows:
|
1 2 3 |
$ echo 'systemctl stop systemd-udevd systemd-udevd-control.socket systemd-udevd-kernel.socket' > stop_systemd_udevd.sh $ sudo chown root.root stop_systemd_udevd.sh $ sudo chmod 4755 stop_systemd_udevd.sh |
Next, run:
|
1 |
$ sudo visudo |
and add the following line at the bottom (this is important) of the /etc/sudoers file.
|
1 |
bob ALL=(root) NOPASSWD: /home/bob/stop_systemd_udevd.sh |
Of course, change bob and /home/bob as needed.
Now you should be able to run
|
1 |
$ sudo ./stop_systemd_udevd.sh |
without being prompted for a password.
The last step is to add execution of this script when your system starts up. Use Startup Application Preferences and add the follow (change /home/bob, of course).
That should do it! Reboot your system and the systemd-udevd service should not be running.
Hope this helps. Enjoy!
Hello, after previous software implementation we had a similiar problems and now it’s time to resolve them. We are looking for a good a good partner. What do you think of this offer on website. Does it look reliable for you based on your experience?
If you are looking for some more help or insight considering dynamics, check our site and blog or just contant us. Cheers.
Very interesting! We also have problems with such things, but fortunately we have many IT specialists who help us solve problems 🙂 Now we are thinking about working with pro 4 people . What do you think about it? I mean cloud solutions, I’m very curious recently about this topic 🙂
The best solution, I invested my hours following other blogs, this is the best solution, which could bring back the life of my died display 🙂