Ubuntu 18.04 Upgrade Problem Resolutions

Original post: Ubuntu 18.04 Upgrade Problem Resolutions

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:

1. "Login Loop": After a valid authentication on the login screen, the display goes black momentarily, and then returns you to the login screen.
2. 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:

$ 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:

$ 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:

$ 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:

$ 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:

$ 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:

$ sudo visudo

and add the following line at the bottom (this is important) of the /etc/sudoers file.

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

$ 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!

Comments

[Slavius]

Not sure, never tried that. But basicaly it seems to be one-man-show as far as I understood it.
Sabayon is not definitely flexible but I found it the best alternative to not have to compile everything by being able to pull binary packages from their repos while still be able to integrate my own compiled apps into existing system with full control I'm used to in Gentoo/Funtoo.

Pretty much works well on my old laptop. If I had a 4c8t cpu and SSD I would go for Gentoo/Funtoo instead and compile on my own (I have no discc either).

[Slavius]

Yes, it may get into your way sometimes but as a long-term Gentoo user you will manage. I'm running Sabayon with mixed emerged packages for over 2 years now without major problems. I still do 'equo update; equo upgrade' - with Sabayon's package manager and emerge packages I need USE flags control; or -9999 versions from git; or are not part of Sabayon's repo - either from layman's repos or just by downloading/creating custom overlay.

[Thang Nguyen]

Login loop has been fixed in Ubuntu 18.04.1.

[Slavius]

Let's try Sabayon. Gentoo based with binary packages.

You still have portage available and you can emerge (compile - note for others) packages into the system (they share the same database).

[Slavius]

Gentoo, Funtoo, Sabayon?

My favorites...

[Artanis]

It works! I just tried the installation of nvodia-352, then the loop login issue was immediately fixed!

[p-mcgowan]

I had the login loop on 16.04 intermittently, always after upgrading nvidia drivers. I spent days on different occasions searchong for the answer. No issues on 18.04 though - wish I saw this then!