'Authentication Error' at lock-screen after release upgrade

Bug #1982183 reported by James McKenzie
22
This bug affects 5 people
Affects Status Importance Assigned to Milestone
ubuntu-release-upgrader (Ubuntu)
Confirmed
Low
Unassigned

Bug Description

After a successful do-release-upgrade from Ubuntu 20.04.4 LTS to Ubuntu 22.04 LTS, if the screen locks before performing a reboot, I am presented with an 'Authentication Error' at the lock screen and cannot authenticate to unlock.

Both SSH and TTY login is still working (we use SSSD and LDAP to authenticate users and this still functions after the upgrade). Only lock-screen authentication seems to be affected.

Rebooting the machine seems to fix this, but means any open files will be forcefully closed without saving.

ProblemType: Bug
DistroRelease: Ubuntu 22.04
Package: ubuntu-release-upgrader-core 1:22.04.11
ProcVersionSignature: Ubuntu 5.15.0-41.44~20.04.1-generic 5.15.39
Uname: Linux 5.15.0-41-generic x86_64
ApportVersion: 2.20.11-0ubuntu82.1
Architecture: amd64
CasperMD5CheckResult: unknown
CrashDB: ubuntu
CrashReports:
 640:8046:125:42956:2022-07-19 14:15:50.903688669 +0100:2022-07-19 14:15:51.903688669 +0100:/var/crash/_usr_share_apport_apport-gtk.8046.crash
 640:8046:125:3482736:2022-07-19 14:15:50.346358299 +0100:2022-07-19 14:15:51.346358299 +0100:/var/crash/_usr_libexec_tracker-extract.8046.crash
Date: Tue Jul 19 14:51:26 2022
InstallationDate: Installed on 2022-07-15 (3 days ago)
InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731)
PackageArchitecture: all
RebootRequiredPkgs: Error: path contained symlinks.
SourcePackage: ubuntu-release-upgrader
Symptom: ubuntu-release-upgrader
UpgradeStatus: Upgraded to jammy on 2022-07-19 (0 days ago)
VarLogDistupgradeXorgFixuplog:
 INFO:root:/usr/bin/do-release-upgrade running
 INFO:root:No xorg.conf, exiting
modified.conffile..etc.update-manager.release-upgrades:
 [default]
   Prompt=lts
mtime.conffile..etc.update-manager.release-upgrades: 2022-07-19T14:10:45.907460

Revision history for this message
James McKenzie (jamesps) wrote :
Revision history for this message
James McKenzie (jamesps) wrote :
Revision history for this message
James McKenzie (jamesps) wrote :

From further testing, I found this only occurs when performing an upgrade with the 'DistUpgradeViewNonInteractive' frontend.

The lock screen is inhibited during the upgrade, but seems to be re-enabled after the non-interactive upgrade. This isn't the case for a GUI upgrade.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Ran do-release-upgrade from a terminal and got the same problem. Seems screen lock isn't inhibited anymore after a while and then login broken until reboot.
I was going into a local console to guide the upgrade to complete before reboot as it was still ongoing. When I found it it was stuck at the popup (I was not running non interactive) that told me that Firefox will change to a snap (seen from ps output).

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in ubuntu-release-upgrader (Ubuntu):
status: New → Confirmed
Revision history for this message
Sam Osheroff (osheros) wrote :

For those finding this page after having a similar experience performing the upgrade using "do-release-upgrade" yet now being stuck, I'm posting a tip to get unstuck. I found my upgrade process stuck (per /var/log/dist-upgrade/screen.0) at the "Remove Packages?" prompt.

The solution for this is that fortunately running the do-release-upgrade from a terminal window in the X-console launches that terminal into a "screen" session. SSH to your box, run "screen -list" to find the name and then "screen -d -r <name>" (e.g. screen -d -r ubuntu-release-upgrade-screen-window) to reconnect the terminal session window to your SSH session. You can then answer the prompt and continue the upgrade.

Revision history for this message
Nick Rosbrook (enr0n) wrote :

The lockscreen inhibitor is only active as long as the u-r-u process is. This is probably why the issue is more apparent with the non-interactive frontend, because it will exit silently, whereas the text frontend would prompt the user to reboot (and many users would just accept).

IIRC the D-Bus service invalidates the inhibitor after the calling process exits, so I don't think there is anything u-r-u can do to ensure the inhibitor stays in place after it exits.

Changed in ubuntu-release-upgrader (Ubuntu):
importance: Undecided → Low
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.