Comment 0 for bug 1778817

During a release upgrade, the screen should not be locked because the upgrade of underlying libraries may leave the system in an inconsistent state where the process locking the screen may not be able to unlock it again.

There is code in the ubuntu-release-upgrader to handle this (DistUpgrade/DistUpgradeQuirks.py:DistUpgradeQuirks._inhibitIdle).

I have just started a release upgrade of an Ubuntu desktop from xenial to bionic with update-manager -d. After leaving it unattended for a while, I came back to find the screen was locked.

/var/log/auth.log includes messages such as:

Jun 26 16:00:45 epona compiz: PAM unable to dlopen(pam_unix.so): /lib/security/pam_unix.so: cannot open shared object file: No such file or directory

This indicates a problem dlopen()ing the PAM modules (actual path: /lib/x86_64-linux-gnu/security/pam_unix.so) because some ABI has changed in the system libraries, and the copy loaded into the running compiz process does not have the symbols required in order to run this module.

This is the exact reason the screensaver is supposed to be inhibited on upgrade.

This is also why every sensible screensaver spawns a fresh helper process to handle the authentication through PAM. compiz (unity), apparently, does not.

I do not yet know what symbols have changed to cause this failure. I'm still investigating that.