Activity log for bug #1778817

Date Who What changed Old value New value Message
2018-06-26 23:27:02 Steve Langasek bug added bug
2018-06-26 23:27:08 Steve Langasek ubuntu-release-upgrader (Ubuntu): importance Undecided Critical
2018-06-26 23:27:21 Steve Langasek ubuntu-release-upgrader (Ubuntu): status New Triaged
2018-06-26 23:41:45 Steve Langasek nominated for series Ubuntu Bionic
2018-06-26 23:41:45 Steve Langasek bug task added ubuntu-release-upgrader (Ubuntu Bionic)
2018-06-26 23:41:52 Steve Langasek bug task added compiz (Ubuntu)
2018-06-26 23:42:19 Steve Langasek compiz (Ubuntu): importance Undecided Critical
2018-06-26 23:42:21 Steve Langasek ubuntu-release-upgrader (Ubuntu Bionic): importance Undecided Critical
2018-06-26 23:42:23 Steve Langasek compiz (Ubuntu Bionic): importance Undecided Critical
2018-06-26 23:42:26 Steve Langasek ubuntu-release-upgrader (Ubuntu Bionic): status New Triaged
2018-06-27 12:22:41 Francis Ginther tags id-5b32dfc70f54891287c5942a
2018-07-03 13:50:44 Will Cooke ubuntu-release-upgrader (Ubuntu): assignee Jean-Baptiste Lallement (jibel)
2018-07-03 13:50:50 Will Cooke ubuntu-release-upgrader (Ubuntu): assignee Jean-Baptiste Lallement (jibel)
2018-07-03 19:19:55 Brian Murray bug added subscriber Brian Murray
2018-07-05 07:41:04 Steve Langasek attachment added main.log https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1778817/+attachment/5159864/+files/main.log
2018-07-05 22:37:10 Brian Murray ubuntu-release-upgrader (Ubuntu): assignee Brian Murray (brian-murray)
2018-07-05 22:37:13 Brian Murray ubuntu-release-upgrader (Ubuntu): status Triaged In Progress
2018-07-05 23:23:05 Launchpad Janitor branch linked lp:~brian-murray/ubuntu-release-upgrader/improve-inhibit-idle
2018-07-06 17:58:15 Launchpad Janitor branch linked lp:ubuntu-release-upgrader
2018-07-06 20:27:37 Launchpad Janitor ubuntu-release-upgrader (Ubuntu): status In Progress Fix Released
2018-07-06 22:15:56 Brian Murray ubuntu-release-upgrader (Ubuntu Bionic): assignee Brian Murray (brian-murray)
2018-07-10 00:04:23 Brian Murray description 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. [Impact] 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. (Its possible for the screen to lock during the fetching process before the call to inhibitIdle happens.) [Test Case] 1) Configure a screen lock with a short time period (1 minute) and ensure it'll take more than 1 minute to fetch all the packages 2) Upgrade an Ubuntu 16.04 system to Ubuntu 18.04 3) Observe the screen locks during the upgrade process With the version of ubuntu-release-upgrader from -proposed the screen will not lock during the fetching process. I wasn't able to recreate the bug where the system would not unlock testing that the screen doesn't lock should be sufficient to verify this. [Regression Potential] Code is just being moved from DistUpgradeQuirks.py to DistUpgradeController.py but its possible a mistake was made so this should be tested carefully. [Original Description] 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.
2018-07-10 00:04:31 Brian Murray ubuntu-release-upgrader (Ubuntu Bionic): status Triaged In Progress
2018-07-11 09:30:48 Łukasz Zemczak ubuntu-release-upgrader (Ubuntu Bionic): status In Progress Fix Committed
2018-07-11 09:30:49 Łukasz Zemczak bug added subscriber Ubuntu Stable Release Updates Team
2018-07-11 09:30:51 Łukasz Zemczak bug added subscriber SRU Verification
2018-07-11 09:30:53 Łukasz Zemczak tags id-5b32dfc70f54891287c5942a id-5b32dfc70f54891287c5942a verification-needed verification-needed-bionic
2018-07-16 20:44:19 Brian Murray description [Impact] 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. (Its possible for the screen to lock during the fetching process before the call to inhibitIdle happens.) [Test Case] 1) Configure a screen lock with a short time period (1 minute) and ensure it'll take more than 1 minute to fetch all the packages 2) Upgrade an Ubuntu 16.04 system to Ubuntu 18.04 3) Observe the screen locks during the upgrade process With the version of ubuntu-release-upgrader from -proposed the screen will not lock during the fetching process. I wasn't able to recreate the bug where the system would not unlock testing that the screen doesn't lock should be sufficient to verify this. [Regression Potential] Code is just being moved from DistUpgradeQuirks.py to DistUpgradeController.py but its possible a mistake was made so this should be tested carefully. [Original Description] 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. [Impact] 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. (Its possible for the screen to lock during the fetching process before the call to inhibitIdle happens.) [Test Case] 1) Configure a screen lock with a short time period (1 minute) and ensure it'll take more than 1 minute to fetch all the packages 2) Upgrade an Ubuntu 16.04 system to Ubuntu 18.04 3) Observe the screen locks during the upgrade process With the version of ubuntu-release-upgrader from -proposed the screen will not lock during the fetching process. I wasn't able to recreate the bug where the system would not unlock but testing that the screen doesn't lock should be sufficient to verify this. [Regression Potential] Code is just being moved from DistUpgradeQuirks.py to DistUpgradeController.py but its possible a mistake was made so this should be tested carefully. [Original Description] 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.
2018-07-16 22:25:16 Brian Murray tags id-5b32dfc70f54891287c5942a verification-needed verification-needed-bionic id-5b32dfc70f54891287c5942a verification-done verification-done-bionic
2018-07-19 12:50:48 Launchpad Janitor ubuntu-release-upgrader (Ubuntu Bionic): status Fix Committed Fix Released
2018-07-19 12:51:05 Steve Langasek removed subscriber Ubuntu Stable Release Updates Team
2018-12-18 14:40:22 Andrea Azzarone compiz (Ubuntu): status New Invalid
2018-12-18 14:40:25 Andrea Azzarone compiz (Ubuntu Bionic): status New Invalid
2018-12-19 00:24:40 Steve Langasek compiz (Ubuntu): status Invalid Triaged
2021-03-29 19:05:38 a59ff5 compiz (Ubuntu Bionic): status Invalid Fix Released
2021-03-29 19:06:11 a59ff5 compiz (Ubuntu): status Triaged Fix Released
2021-03-29 20:56:30 Colin Watson compiz (Ubuntu Bionic): status Fix Released Invalid
2021-03-29 20:56:33 Colin Watson compiz (Ubuntu): status Fix Released Triaged