Ubuntu – 18.04 – Failing to shutdown/power off on AMD Ryzen CPUs

18.04kernelrebootshutdown

When booting up Ubuntu 18.04 with a kernel version of 5.3.0-52 or later (including 5.3.0-53), everything seems to be working as usual. However, when I shutdown, the system will only soft shutdown, with the CPU still running at full power, forcing me to hold down the power button to fully power off affected systems. If I reboot, it will cause the system to hang and not respond. Either way, a hard reset or poweroff will be required, and this is not an option for systems being remotely accessed. It is not possible for me to collect kernel logs at this point, unless something wrong is happening in those kernel versions before the actual shutdown.

It is possible that this may also occur on Ubuntu 20.04 with kernel versions 5.4.0-29 and later, but I have not yet tested this out. This problem is occurring on both my desktop and laptop computers which respectively are:

AsRock B450 Pro4 with AMD Ryzen 3 3200G APU
Lenovo ThinkPad A485 with AMD Ryzen 5 Pro 2500U mobile APU

In the meantime, I am stuck on kernel version 5.3.0-51, as that is the last working 5.3.x kernel version offered in the standard Ubuntu repositories that doesn't have this problem, without me having to use PPAs. I don't know if this problem also occurs on systems with Intel CPUs, as I don't own any recently-made system (last 3 years from 2017) with such CPUs to test if this problem occurs on them.

Update: Reboots are also affected, not only shutdowns.

Best Answer

I had the same problem with the brand new T495 AMD Ryzen 7 PRO 3700U. I manage to solve it on 5.3.0-53 by installing AMD drivers from here https://www.amd.com/en/support/kb/release-notes/rn-amdgpu-unified-linux-20-10

The 5.3.0-51-generic didn't work for me from the beginning (it hangs on the login screen - I'm using unity instead of gnome)

Hope it helps

Looking around to get closer to the root cause

The problem seems to be the script running at shutdown.

I identified the corresponding file with:

find /etc/systemd -name *unattended*

which gaves me the related systemd script:

/etc/systemd/system/shutdown.target.wants/unattended-upgrades.service

which then told me the script executed on shutdown:

/usr/share/unattended-upgrades/unattended-upgrade-shutdown

Investigating deeper to find the root cause

within this script there is a section in line 120 related to the section in /etc/apt/apt.conf.d/50unattended-upgrades -> Unattended-Upgrade::InstallOnShutdown

Line 120 of /usr/share/unattended-upgrades/unattended-upgrade-shutdown:

if apt_pkg.config.find_b("Unattended-Upgrade::InstallOnShutdown", False):

The problem: it expects the keyword "False" while in the apt conf we should add "false" (exact string comparison)!

Solution

I was able to fix/workaround the stalling shutdown in 3 different ways:

Workaround A

write "False" instead of "false" in /etc/apt/apt.conf.d/50unattended-upgrades

This setting is upgrade safe until a real fix is provided because the file we change here gets not overwritten by an update of unattended-upgrades. Problem: When the root cause gets fixed this will result in a stalling shutdown again so I suggest to combine this with Workaround B.

OR: Workaround B

decrease the wait time in /etc/systemd/system/shutdown.target.wants/unattended-upgrades.service from default to 15 seconds:

vim /etc/systemd/system/shutdown.target.wants/unattended-upgrades.service

[Service]
Type=oneshot
ExecStart=/usr/share/unattended-upgrades/unattended-upgrade-shutdown
TimeoutStartSec=15

This setting is NOT upgrade safe because the file we change here may get overwritten by an update of unattended-upgrades. Besides this it is really far away from fixing something but it will ensure that your system will not wait several minutes when shutting down. Keep in mind that after an upgrade of unattended-upgrades you may have to set this again!

OR: Fix C (have to be reported upstream)

fix /usr/share/unattended-upgrades/unattended-upgrades-shutdown to expect "false" instead of "False"

patching /usr/share/unattended-upgrades/unattended-upgrade-shutdown:

--- /tmp/unattended-upgrade-shutdown    2017-02-03 14:53:03.238103238 +0100
+++ /tmp/unattended-upgrade-shutdown_fix    2017-02-03 14:53:17.685589001 +0100
@@ -117,7 +117,7 @@
     # run it
     p = None
     apt_pkg.init_config()
-    if apt_pkg.config.find_b("Unattended-Upgrade::InstallOnShutdown", False):
+    if apt_pkg.config.find_b("Unattended-Upgrade::InstallOnShutdown", false):
         env = copy.copy(os.environ)
         env["UNATTENDED_UPGRADES_FORCE_INSTALL_ON_SHUTDOWN"] = "1"
         logging.debug("starting unattended-upgrades in shutdown mode")

Conclusion

tbh only the last one is a real fix. the both other options are just workarounds until the real fix would be implemented.

This has to be done upstream and as this affects both Debian (tested on Debian Stretch) and Ubuntu (tested on Ubuntu 16.04.1) for both distributions.

I have opened a bug report here: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1661611

Ubuntu – What can be harmed by incorrect power off, and what can be checked

The easiest way to check the ext4 file system is to add

fsck.mode=force

as a boot parameter.

It can be done in /etc/default/grub, or manually on boot.

For older systems that use upstart run

sudo touch /forcefsck

and reboot.

The command will create an empty /forcefsck file that will tell the system to check drives on boot.

On boot, before the file system is mounted fsck will run and show if there are errors.

Otherwise you will need to boot from some external device.