| 2020-02-28 20:23:43 |
Simon Déziel |
bug |
|
|
added bug |
| 2020-03-04 18:17:18 |
Andreas Hasenack |
php-defaults (Ubuntu): status |
New |
Triaged |
|
| 2020-03-04 18:17:20 |
Andreas Hasenack |
php-defaults (Ubuntu): importance |
Undecided |
High |
|
| 2020-03-04 18:17:31 |
Andreas Hasenack |
bug |
|
|
added subscriber Ubuntu Server |
| 2020-04-14 17:40:25 |
Rafael David Tinoco |
tags |
|
server-triage-discuss |
|
| 2020-04-14 17:43:12 |
Rafael David Tinoco |
bug |
|
|
added subscriber Andreas Hasenack |
| 2020-04-14 17:43:18 |
Rafael David Tinoco |
tags |
server-triage-discuss |
|
|
| 2020-04-14 20:08:55 |
Bryce Harrington |
bug watch added |
|
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893481 |
|
| 2020-04-14 20:08:55 |
Bryce Harrington |
bug watch added |
|
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911738 |
|
| 2020-04-14 20:10:55 |
Bryce Harrington |
bug task added |
|
php-defaults (Debian) |
|
| 2020-04-14 20:11:21 |
Bryce Harrington |
affects |
php-defaults (Ubuntu) |
php7.4 (Ubuntu) |
|
| 2020-04-14 20:11:35 |
Bryce Harrington |
affects |
php-defaults (Debian) |
php7.4 (Debian) |
|
| 2020-04-15 04:18:26 |
Bug Watch Updater |
php7.4 (Debian): status |
Unknown |
New |
|
| 2020-05-13 05:25:36 |
Bryce Harrington |
description |
Yesterday, when upgrading a client VMs running Xenial and moving to Bionic, I noticed Apache's mod_php was disabled. I later reproduced this in a container:
# create a Xenial container
$ lxc launch images:ubuntu/xenial xa
Creating xa
Starting xa
# Install Apache mod_php
$ lxc shell xa
mesg: ttyname failed: Success
root@xa:~# apt-get install libapache2-mod-php
Reading package lists... Done
Building dependency tree
Reading state information... Done
...
Unpacking libapache2-mod-php7.0 (7.0.33-0ubuntu0.16.04.12) ...
...
apache2_switch_mpm Switch to prefork
apache2_invoke: Enable module php7.0
# Upgrade to Bionic
root@xa:~# apt-get install ubuntu-release-upgrader-core
...
root@xa:~# do-release-upgrade
...
Creating config file /etc/php/7.2/cli/php.ini with new version
Setting up libapache2-mod-php7.2 (7.2.24-0ubuntu0.18.04.3) ...
Creating config file /etc/php/7.2/apache2/php.ini with new version
libapache2-mod-php7.2: php7.0 module already enabled, not enabling PHP 7.2
Setting up libapache2-mod-php (1:7.2+60ubuntu1) ...
...
Removing libapache2-mod-php7.0 (7.0.33-0ubuntu0.16.04.12) ...
Module php7.0 disabled.
apache2_invoke prerm: Disable module php7.0
Purging configuration files for libapache2-mod-php7.0 (7.0.33-0ubuntu0.16.04.12) ...
apache2_invoke postrm: Purging state for php7.0
dpkg: warning: while removing libapache2-mod-php7.0, directory '/etc/php/7.0/apache2/conf.d' not empty so not removed
...
System upgrade is complete.
Restart required
To finish the upgrade, a restart is required.
If you select 'y' the system will be restarted.
Continue [yN] y
Additional information on the upgraded container:
root@xa:~# lsb_release -rd
Description: Ubuntu 18.04.4 LTS
Release: 18.04
root@xa:~# apt-cache policy libapache2-mod-php7.2
libapache2-mod-php7.2:
Installed: 7.2.24-0ubuntu0.18.04.3
Candidate: 7.2.24-0ubuntu0.18.04.3
Version table:
*** 7.2.24-0ubuntu0.18.04.3 500
500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages
100 /var/lib/dpkg/status
7.2.3-1ubuntu1 500
500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages |
[Impact]
A normal upgrade of a properly functioning PHP website server can unexpectedly result in disabling PHP, when there are no misconfigurations or other actual errors. It's also easy to miss the error message, thus making it more challenging to notice the site breakage.
[Fix]
Instead of issuing an err when there is already one or more active apache mod for php(s) of a different version, issue a warning and disable it.
[Test Case]
For bionic -> focal upgrades:
$ lxc launch ubuntu:18.04/amd64 ba
$ lxc exec ba -- bash
# apt-get install -y libapache2-mod-php
# apt-get install -y ubuntu-release-upgrader-core
# do-release-upgrade -d
+ Answer defaults for everything
+ Allow it to reboot when done, and log back in
For eoan -> focal upgrades:
$ lxc launch ubuntu:18.04/amd64 ba
$ lxc exec ba -- bash
# apt-get install -y libapache2-mod-php
# apt-get install -y ubuntu-release-upgrader-core
# do-release-upgrade -d
+ Answer defaults for everything
+ Allow it to reboot when done, and log back in
For either case, to verify the error is present:
# journalctl --boot | grep libapache2-mod-php7.4 | grep php7.[23] | cut -d: -f5
php7.3 module already enabled, not enabling PHP 7.4
# apt-cache policy libapache2-mod-php* | grep -B1 Installed
libapache2-mod-php:
Installed: 2:7.4+75
--
libapache2-mod-php5:
Installed: (none)
--
libapache2-mod-php7.2:
Installed: (none)
--
libapache2-mod-php7.3:
Installed: (none)
--
libapache2-mod-php7.4:
Installed: 7.4.3-4ubuntu1
To verify the fix (for bionic; eoan is similar):
$ lxc launch ubuntu:18.04/amd64 bb
$ lxc exec bb -- bash
# apt-get -y install software-properties-common
# add-apt-repository -yus ppa:bryce/php-defaults-fix-lp1865218-mod-php-upgrade
# apt-cache policy libapache2-mod-php7.2
+ Verify the new version is available
# apt-get install -y libapache2-mod-php
# apt-cache policy libapache2-mod-php7.2
+ Verify the new version is installed
# apt-get install -y ubuntu-release-upgrader-core
# apt-get upgrade -y
# do-release-upgrade -d
+ Answer defaults for everything
+ Allow it to reboot when done, and log back in
# Verify the 7.4 version is installed
apt-cache policy libapache2-mod-php* | grep -B1 Installed
# Verify error is not present
journalctl --boot | grep libapache2-mod-php7.4 | grep php7.[23] | cut -d: -f5
[Regression Potential]
Since this change affects only the installer's upgrade logic, the thing to keep an eye on would be behavioral changes during upgrades or, possibly, during installation.
Presumably the rationale for the current behavior of refusing to disable an already running mod-php is if the user had intentionally installed a non-distro managed or self-modified mod-php. Upgrading in such a situation might result in unexpected behavior changes. However, this custom configuration is unlikely to be common, and should be expected to be affected during a system upgrade.
[Original Report]
Yesterday, when upgrading a client VMs running Xenial and moving to Bionic, I noticed Apache's mod_php was disabled. I later reproduced this in a container:
# create a Xenial container
$ lxc launch images:ubuntu/xenial xa
Creating xa
Starting xa
# Install Apache mod_php
$ lxc shell xa
mesg: ttyname failed: Success
root@xa:~# apt-get install libapache2-mod-php
Reading package lists... Done
Building dependency tree
Reading state information... Done
...
Unpacking libapache2-mod-php7.0 (7.0.33-0ubuntu0.16.04.12) ...
...
apache2_switch_mpm Switch to prefork
apache2_invoke: Enable module php7.0
# Upgrade to Bionic
root@xa:~# apt-get install ubuntu-release-upgrader-core
...
root@xa:~# do-release-upgrade
...
Creating config file /etc/php/7.2/cli/php.ini with new version
Setting up libapache2-mod-php7.2 (7.2.24-0ubuntu0.18.04.3) ...
Creating config file /etc/php/7.2/apache2/php.ini with new version
libapache2-mod-php7.2: php7.0 module already enabled, not enabling PHP 7.2
Setting up libapache2-mod-php (1:7.2+60ubuntu1) ...
...
Removing libapache2-mod-php7.0 (7.0.33-0ubuntu0.16.04.12) ...
Module php7.0 disabled.
apache2_invoke prerm: Disable module php7.0
Purging configuration files for libapache2-mod-php7.0 (7.0.33-0ubuntu0.16.04.12) ...
apache2_invoke postrm: Purging state for php7.0
dpkg: warning: while removing libapache2-mod-php7.0, directory '/etc/php/7.0/apache2/conf.d' not empty so not removed
...
System upgrade is complete.
Restart required
To finish the upgrade, a restart is required.
If you select 'y' the system will be restarted.
Continue [yN] y
Additional information on the upgraded container:
root@xa:~# lsb_release -rd
Description: Ubuntu 18.04.4 LTS
Release: 18.04
root@xa:~# apt-cache policy libapache2-mod-php7.2
libapache2-mod-php7.2:
Installed: 7.2.24-0ubuntu0.18.04.3
Candidate: 7.2.24-0ubuntu0.18.04.3
Version table:
*** 7.2.24-0ubuntu0.18.04.3 500
500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages
100 /var/lib/dpkg/status
7.2.3-1ubuntu1 500
500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages |
|
| 2020-05-13 05:34:06 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~bryce/ubuntu/+source/php7.3/+git/php7.3/+merge/383846 |
|
| 2020-05-13 05:34:09 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~bryce/ubuntu/+source/php7.2/+git/php7.2/+merge/383847 |
|
| 2020-05-13 05:34:15 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~bryce/ubuntu/+source/php7.4/+git/php7.4/+merge/383849 |
|
| 2020-05-13 05:34:12 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~bryce/ubuntu/+source/php7.4/+git/php7.4/+merge/383848 |
|
| 2020-05-14 19:19:54 |
Jordan |
bug |
|
|
added subscriber Jordan |
| 2020-05-15 12:54:51 |
Launchpad Janitor |
php7.4 (Ubuntu): status |
Triaged |
Fix Released |
|
| 2020-05-15 23:53:25 |
Bryce Harrington |
nominated for series |
|
Ubuntu Groovy |
|
| 2020-05-15 23:53:25 |
Bryce Harrington |
bug task added |
|
php7.4 (Ubuntu Groovy) |
|
| 2020-05-15 23:53:25 |
Bryce Harrington |
nominated for series |
|
Ubuntu Bionic |
|
| 2020-05-15 23:53:25 |
Bryce Harrington |
bug task added |
|
php7.4 (Ubuntu Bionic) |
|
| 2020-05-15 23:53:25 |
Bryce Harrington |
nominated for series |
|
Ubuntu Eoan |
|
| 2020-05-15 23:53:25 |
Bryce Harrington |
bug task added |
|
php7.4 (Ubuntu Eoan) |
|
| 2020-05-15 23:53:25 |
Bryce Harrington |
nominated for series |
|
Ubuntu Focal |
|
| 2020-05-15 23:53:25 |
Bryce Harrington |
bug task added |
|
php7.4 (Ubuntu Focal) |
|
| 2020-05-15 23:53:40 |
Bryce Harrington |
php7.4 (Ubuntu Focal): status |
New |
Fix Committed |
|
| 2020-05-15 23:53:42 |
Bryce Harrington |
php7.4 (Ubuntu Eoan): status |
New |
Fix Committed |
|
| 2020-05-15 23:53:45 |
Bryce Harrington |
php7.4 (Ubuntu Bionic): status |
New |
Fix Committed |
|
| 2020-05-15 23:53:48 |
Bryce Harrington |
php7.4 (Ubuntu Focal): importance |
Undecided |
High |
|
| 2020-05-15 23:53:50 |
Bryce Harrington |
php7.4 (Ubuntu Eoan): importance |
Undecided |
Medium |
|
| 2020-05-15 23:53:53 |
Bryce Harrington |
php7.4 (Ubuntu Bionic): importance |
Undecided |
High |
|
| 2020-05-15 23:53:57 |
Bryce Harrington |
php7.4 (Ubuntu Bionic): assignee |
|
Bryce Harrington (bryce) |
|
| 2020-05-15 23:53:58 |
Bryce Harrington |
php7.4 (Ubuntu Eoan): assignee |
|
Bryce Harrington (bryce) |
|
| 2020-05-15 23:54:00 |
Bryce Harrington |
php7.4 (Ubuntu Focal): assignee |
|
Bryce Harrington (bryce) |
|
| 2020-05-15 23:54:01 |
Bryce Harrington |
php7.4 (Ubuntu Groovy): assignee |
|
Bryce Harrington (bryce) |
|
| 2020-05-22 21:51:04 |
Steve Langasek |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2020-05-22 21:51:06 |
Steve Langasek |
bug |
|
|
added subscriber SRU Verification |
| 2020-05-22 21:51:11 |
Steve Langasek |
tags |
|
verification-needed verification-needed-focal |
|
| 2020-05-22 21:53:56 |
Steve Langasek |
bug task added |
|
php7.3 (Ubuntu) |
|
| 2020-05-22 21:54:05 |
Steve Langasek |
php7.3 (Ubuntu Eoan): status |
New |
In Progress |
|
| 2020-05-22 21:54:23 |
Steve Langasek |
bug task deleted |
php7.3 (Ubuntu Focal) |
|
|
| 2020-05-22 21:54:30 |
Steve Langasek |
bug task deleted |
php7.3 (Ubuntu Groovy) |
|
|
| 2020-05-22 21:54:40 |
Steve Langasek |
bug task deleted |
php7.4 (Ubuntu Eoan) |
|
|
| 2020-05-22 21:54:51 |
Steve Langasek |
bug task deleted |
php7.4 (Ubuntu Bionic) |
|
|
| 2020-05-22 21:56:45 |
Steve Langasek |
php7.3 (Ubuntu Eoan): status |
In Progress |
Fix Committed |
|
| 2020-05-22 21:56:53 |
Steve Langasek |
tags |
verification-needed verification-needed-focal |
verification-needed verification-needed-eoan verification-needed-focal |
|
| 2020-05-22 21:58:41 |
Steve Langasek |
bug task added |
|
php7.2 (Ubuntu) |
|
| 2020-05-22 21:59:02 |
Steve Langasek |
bug task deleted |
php7.3 (Ubuntu Bionic) |
|
|
| 2020-05-22 21:59:10 |
Steve Langasek |
php7.2 (Ubuntu): status |
New |
Invalid |
|
| 2020-05-22 21:59:13 |
Steve Langasek |
php7.3 (Ubuntu): status |
New |
Invalid |
|
| 2020-05-22 22:00:14 |
Steve Langasek |
php7.2 (Ubuntu Bionic): status |
New |
Fix Committed |
|
| 2020-05-22 22:00:21 |
Steve Langasek |
tags |
verification-needed verification-needed-eoan verification-needed-focal |
verification-needed verification-needed-bionic verification-needed-eoan verification-needed-focal |
|
| 2020-05-26 17:05:22 |
Simon Déziel |
description |
[Impact]
A normal upgrade of a properly functioning PHP website server can unexpectedly result in disabling PHP, when there are no misconfigurations or other actual errors. It's also easy to miss the error message, thus making it more challenging to notice the site breakage.
[Fix]
Instead of issuing an err when there is already one or more active apache mod for php(s) of a different version, issue a warning and disable it.
[Test Case]
For bionic -> focal upgrades:
$ lxc launch ubuntu:18.04/amd64 ba
$ lxc exec ba -- bash
# apt-get install -y libapache2-mod-php
# apt-get install -y ubuntu-release-upgrader-core
# do-release-upgrade -d
+ Answer defaults for everything
+ Allow it to reboot when done, and log back in
For eoan -> focal upgrades:
$ lxc launch ubuntu:18.04/amd64 ba
$ lxc exec ba -- bash
# apt-get install -y libapache2-mod-php
# apt-get install -y ubuntu-release-upgrader-core
# do-release-upgrade -d
+ Answer defaults for everything
+ Allow it to reboot when done, and log back in
For either case, to verify the error is present:
# journalctl --boot | grep libapache2-mod-php7.4 | grep php7.[23] | cut -d: -f5
php7.3 module already enabled, not enabling PHP 7.4
# apt-cache policy libapache2-mod-php* | grep -B1 Installed
libapache2-mod-php:
Installed: 2:7.4+75
--
libapache2-mod-php5:
Installed: (none)
--
libapache2-mod-php7.2:
Installed: (none)
--
libapache2-mod-php7.3:
Installed: (none)
--
libapache2-mod-php7.4:
Installed: 7.4.3-4ubuntu1
To verify the fix (for bionic; eoan is similar):
$ lxc launch ubuntu:18.04/amd64 bb
$ lxc exec bb -- bash
# apt-get -y install software-properties-common
# add-apt-repository -yus ppa:bryce/php-defaults-fix-lp1865218-mod-php-upgrade
# apt-cache policy libapache2-mod-php7.2
+ Verify the new version is available
# apt-get install -y libapache2-mod-php
# apt-cache policy libapache2-mod-php7.2
+ Verify the new version is installed
# apt-get install -y ubuntu-release-upgrader-core
# apt-get upgrade -y
# do-release-upgrade -d
+ Answer defaults for everything
+ Allow it to reboot when done, and log back in
# Verify the 7.4 version is installed
apt-cache policy libapache2-mod-php* | grep -B1 Installed
# Verify error is not present
journalctl --boot | grep libapache2-mod-php7.4 | grep php7.[23] | cut -d: -f5
[Regression Potential]
Since this change affects only the installer's upgrade logic, the thing to keep an eye on would be behavioral changes during upgrades or, possibly, during installation.
Presumably the rationale for the current behavior of refusing to disable an already running mod-php is if the user had intentionally installed a non-distro managed or self-modified mod-php. Upgrading in such a situation might result in unexpected behavior changes. However, this custom configuration is unlikely to be common, and should be expected to be affected during a system upgrade.
[Original Report]
Yesterday, when upgrading a client VMs running Xenial and moving to Bionic, I noticed Apache's mod_php was disabled. I later reproduced this in a container:
# create a Xenial container
$ lxc launch images:ubuntu/xenial xa
Creating xa
Starting xa
# Install Apache mod_php
$ lxc shell xa
mesg: ttyname failed: Success
root@xa:~# apt-get install libapache2-mod-php
Reading package lists... Done
Building dependency tree
Reading state information... Done
...
Unpacking libapache2-mod-php7.0 (7.0.33-0ubuntu0.16.04.12) ...
...
apache2_switch_mpm Switch to prefork
apache2_invoke: Enable module php7.0
# Upgrade to Bionic
root@xa:~# apt-get install ubuntu-release-upgrader-core
...
root@xa:~# do-release-upgrade
...
Creating config file /etc/php/7.2/cli/php.ini with new version
Setting up libapache2-mod-php7.2 (7.2.24-0ubuntu0.18.04.3) ...
Creating config file /etc/php/7.2/apache2/php.ini with new version
libapache2-mod-php7.2: php7.0 module already enabled, not enabling PHP 7.2
Setting up libapache2-mod-php (1:7.2+60ubuntu1) ...
...
Removing libapache2-mod-php7.0 (7.0.33-0ubuntu0.16.04.12) ...
Module php7.0 disabled.
apache2_invoke prerm: Disable module php7.0
Purging configuration files for libapache2-mod-php7.0 (7.0.33-0ubuntu0.16.04.12) ...
apache2_invoke postrm: Purging state for php7.0
dpkg: warning: while removing libapache2-mod-php7.0, directory '/etc/php/7.0/apache2/conf.d' not empty so not removed
...
System upgrade is complete.
Restart required
To finish the upgrade, a restart is required.
If you select 'y' the system will be restarted.
Continue [yN] y
Additional information on the upgraded container:
root@xa:~# lsb_release -rd
Description: Ubuntu 18.04.4 LTS
Release: 18.04
root@xa:~# apt-cache policy libapache2-mod-php7.2
libapache2-mod-php7.2:
Installed: 7.2.24-0ubuntu0.18.04.3
Candidate: 7.2.24-0ubuntu0.18.04.3
Version table:
*** 7.2.24-0ubuntu0.18.04.3 500
500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages
100 /var/lib/dpkg/status
7.2.3-1ubuntu1 500
500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages |
[Impact]
A normal upgrade of a properly functioning PHP website server can unexpectedly result in disabling PHP, when there are no misconfigurations or other actual errors. It's also easy to miss the error message, thus making it more challenging to notice the site breakage.
[Fix]
Instead of issuing an err when there is already one or more active apache mod for php(s) of a different version, issue a warning and disable it.
[Test Case]
For bionic -> focal upgrades:
$ lxc launch ubuntu:18.04/amd64 ba
$ lxc exec ba -- bash
# apt-get install -y libapache2-mod-php
# apt-get install -y ubuntu-release-upgrader-core
# do-release-upgrade -d
+ Answer defaults for everything
+ Allow it to reboot when done, and log back in
For eoan -> focal upgrades:
$ lxc launch ubuntu:19.10/amd64 ba
$ lxc exec ba -- bash
# apt-get install -y libapache2-mod-php
# apt-get install -y ubuntu-release-upgrader-core
# do-release-upgrade -d
+ Answer defaults for everything
+ Allow it to reboot when done, and log back in
For either case, to verify the error is present:
# journalctl --boot | grep libapache2-mod-php7.4 | grep php7.[23] | cut -d: -f5
php7.3 module already enabled, not enabling PHP 7.4
# apt-cache policy libapache2-mod-php* | grep -B1 Installed
libapache2-mod-php:
Installed: 2:7.4+75
--
libapache2-mod-php5:
Installed: (none)
--
libapache2-mod-php7.2:
Installed: (none)
--
libapache2-mod-php7.3:
Installed: (none)
--
libapache2-mod-php7.4:
Installed: 7.4.3-4ubuntu1
To verify the fix (for bionic; eoan is similar):
$ lxc launch ubuntu:18.04/amd64 bb
$ lxc exec bb -- bash
# apt-get -y install software-properties-common
# add-apt-repository -yus ppa:bryce/php-defaults-fix-lp1865218-mod-php-upgrade
# apt-cache policy libapache2-mod-php7.2
+ Verify the new version is available
# apt-get install -y libapache2-mod-php
# apt-cache policy libapache2-mod-php7.2
+ Verify the new version is installed
# apt-get install -y ubuntu-release-upgrader-core
# apt-get upgrade -y
# do-release-upgrade -d
+ Answer defaults for everything
+ Allow it to reboot when done, and log back in
# Verify the 7.4 version is installed
apt-cache policy libapache2-mod-php* | grep -B1 Installed
# Verify error is not present
journalctl --boot | grep libapache2-mod-php7.4 | grep php7.[23] | cut -d: -f5
[Regression Potential]
Since this change affects only the installer's upgrade logic, the thing to keep an eye on would be behavioral changes during upgrades or, possibly, during installation.
Presumably the rationale for the current behavior of refusing to disable an already running mod-php is if the user had intentionally installed a non-distro managed or self-modified mod-php. Upgrading in such a situation might result in unexpected behavior changes. However, this custom configuration is unlikely to be common, and should be expected to be affected during a system upgrade.
[Original Report]
Yesterday, when upgrading a client VMs running Xenial and moving to Bionic, I noticed Apache's mod_php was disabled. I later reproduced this in a container:
# create a Xenial container
$ lxc launch images:ubuntu/xenial xa
Creating xa
Starting xa
# Install Apache mod_php
$ lxc shell xa
mesg: ttyname failed: Success
root@xa:~# apt-get install libapache2-mod-php
Reading package lists... Done
Building dependency tree
Reading state information... Done
...
Unpacking libapache2-mod-php7.0 (7.0.33-0ubuntu0.16.04.12) ...
...
apache2_switch_mpm Switch to prefork
apache2_invoke: Enable module php7.0
# Upgrade to Bionic
root@xa:~# apt-get install ubuntu-release-upgrader-core
...
root@xa:~# do-release-upgrade
...
Creating config file /etc/php/7.2/cli/php.ini with new version
Setting up libapache2-mod-php7.2 (7.2.24-0ubuntu0.18.04.3) ...
Creating config file /etc/php/7.2/apache2/php.ini with new version
libapache2-mod-php7.2: php7.0 module already enabled, not enabling PHP 7.2
Setting up libapache2-mod-php (1:7.2+60ubuntu1) ...
...
Removing libapache2-mod-php7.0 (7.0.33-0ubuntu0.16.04.12) ...
Module php7.0 disabled.
apache2_invoke prerm: Disable module php7.0
Purging configuration files for libapache2-mod-php7.0 (7.0.33-0ubuntu0.16.04.12) ...
apache2_invoke postrm: Purging state for php7.0
dpkg: warning: while removing libapache2-mod-php7.0, directory '/etc/php/7.0/apache2/conf.d' not empty so not removed
...
System upgrade is complete.
Restart required
To finish the upgrade, a restart is required.
If you select 'y' the system will be restarted.
Continue [yN] y
Additional information on the upgraded container:
root@xa:~# lsb_release -rd
Description: Ubuntu 18.04.4 LTS
Release: 18.04
root@xa:~# apt-cache policy libapache2-mod-php7.2
libapache2-mod-php7.2:
Installed: 7.2.24-0ubuntu0.18.04.3
Candidate: 7.2.24-0ubuntu0.18.04.3
Version table:
*** 7.2.24-0ubuntu0.18.04.3 500
500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages
100 /var/lib/dpkg/status
7.2.3-1ubuntu1 500
500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages |
|
| 2020-05-26 18:49:35 |
Simon Déziel |
description |
[Impact]
A normal upgrade of a properly functioning PHP website server can unexpectedly result in disabling PHP, when there are no misconfigurations or other actual errors. It's also easy to miss the error message, thus making it more challenging to notice the site breakage.
[Fix]
Instead of issuing an err when there is already one or more active apache mod for php(s) of a different version, issue a warning and disable it.
[Test Case]
For bionic -> focal upgrades:
$ lxc launch ubuntu:18.04/amd64 ba
$ lxc exec ba -- bash
# apt-get install -y libapache2-mod-php
# apt-get install -y ubuntu-release-upgrader-core
# do-release-upgrade -d
+ Answer defaults for everything
+ Allow it to reboot when done, and log back in
For eoan -> focal upgrades:
$ lxc launch ubuntu:19.10/amd64 ba
$ lxc exec ba -- bash
# apt-get install -y libapache2-mod-php
# apt-get install -y ubuntu-release-upgrader-core
# do-release-upgrade -d
+ Answer defaults for everything
+ Allow it to reboot when done, and log back in
For either case, to verify the error is present:
# journalctl --boot | grep libapache2-mod-php7.4 | grep php7.[23] | cut -d: -f5
php7.3 module already enabled, not enabling PHP 7.4
# apt-cache policy libapache2-mod-php* | grep -B1 Installed
libapache2-mod-php:
Installed: 2:7.4+75
--
libapache2-mod-php5:
Installed: (none)
--
libapache2-mod-php7.2:
Installed: (none)
--
libapache2-mod-php7.3:
Installed: (none)
--
libapache2-mod-php7.4:
Installed: 7.4.3-4ubuntu1
To verify the fix (for bionic; eoan is similar):
$ lxc launch ubuntu:18.04/amd64 bb
$ lxc exec bb -- bash
# apt-get -y install software-properties-common
# add-apt-repository -yus ppa:bryce/php-defaults-fix-lp1865218-mod-php-upgrade
# apt-cache policy libapache2-mod-php7.2
+ Verify the new version is available
# apt-get install -y libapache2-mod-php
# apt-cache policy libapache2-mod-php7.2
+ Verify the new version is installed
# apt-get install -y ubuntu-release-upgrader-core
# apt-get upgrade -y
# do-release-upgrade -d
+ Answer defaults for everything
+ Allow it to reboot when done, and log back in
# Verify the 7.4 version is installed
apt-cache policy libapache2-mod-php* | grep -B1 Installed
# Verify error is not present
journalctl --boot | grep libapache2-mod-php7.4 | grep php7.[23] | cut -d: -f5
[Regression Potential]
Since this change affects only the installer's upgrade logic, the thing to keep an eye on would be behavioral changes during upgrades or, possibly, during installation.
Presumably the rationale for the current behavior of refusing to disable an already running mod-php is if the user had intentionally installed a non-distro managed or self-modified mod-php. Upgrading in such a situation might result in unexpected behavior changes. However, this custom configuration is unlikely to be common, and should be expected to be affected during a system upgrade.
[Original Report]
Yesterday, when upgrading a client VMs running Xenial and moving to Bionic, I noticed Apache's mod_php was disabled. I later reproduced this in a container:
# create a Xenial container
$ lxc launch images:ubuntu/xenial xa
Creating xa
Starting xa
# Install Apache mod_php
$ lxc shell xa
mesg: ttyname failed: Success
root@xa:~# apt-get install libapache2-mod-php
Reading package lists... Done
Building dependency tree
Reading state information... Done
...
Unpacking libapache2-mod-php7.0 (7.0.33-0ubuntu0.16.04.12) ...
...
apache2_switch_mpm Switch to prefork
apache2_invoke: Enable module php7.0
# Upgrade to Bionic
root@xa:~# apt-get install ubuntu-release-upgrader-core
...
root@xa:~# do-release-upgrade
...
Creating config file /etc/php/7.2/cli/php.ini with new version
Setting up libapache2-mod-php7.2 (7.2.24-0ubuntu0.18.04.3) ...
Creating config file /etc/php/7.2/apache2/php.ini with new version
libapache2-mod-php7.2: php7.0 module already enabled, not enabling PHP 7.2
Setting up libapache2-mod-php (1:7.2+60ubuntu1) ...
...
Removing libapache2-mod-php7.0 (7.0.33-0ubuntu0.16.04.12) ...
Module php7.0 disabled.
apache2_invoke prerm: Disable module php7.0
Purging configuration files for libapache2-mod-php7.0 (7.0.33-0ubuntu0.16.04.12) ...
apache2_invoke postrm: Purging state for php7.0
dpkg: warning: while removing libapache2-mod-php7.0, directory '/etc/php/7.0/apache2/conf.d' not empty so not removed
...
System upgrade is complete.
Restart required
To finish the upgrade, a restart is required.
If you select 'y' the system will be restarted.
Continue [yN] y
Additional information on the upgraded container:
root@xa:~# lsb_release -rd
Description: Ubuntu 18.04.4 LTS
Release: 18.04
root@xa:~# apt-cache policy libapache2-mod-php7.2
libapache2-mod-php7.2:
Installed: 7.2.24-0ubuntu0.18.04.3
Candidate: 7.2.24-0ubuntu0.18.04.3
Version table:
*** 7.2.24-0ubuntu0.18.04.3 500
500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages
100 /var/lib/dpkg/status
7.2.3-1ubuntu1 500
500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages |
[Impact]
A normal upgrade of a properly functioning PHP website server can unexpectedly result in disabling PHP, when there are no misconfigurations or other actual errors. It's also easy to miss the error message, thus making it more challenging to notice the site breakage.
[Fix]
Instead of issuing an err when there is already one or more active apache mod for php(s) of a different version, issue a warning and disable it.
[Test Case]
For bionic -> focal upgrades:
$ lxc launch ubuntu:18.04/amd64 ba
$ lxc exec ba -- bash
# apt-get install -y libapache2-mod-php
# apt-get install -y ubuntu-release-upgrader-core
# do-release-upgrade -d
+ Answer defaults for everything
+ Allow it to reboot when done, and log back in
For eoan -> focal upgrades:
$ lxc launch ubuntu:19.10/amd64 ea
$ lxc exec ea -- bash
# apt-get install -y libapache2-mod-php
# apt-get install -y ubuntu-release-upgrader-core
# do-release-upgrade
+ Answer defaults for everything
+ Allow it to reboot when done, and log back in
For either case, to verify the error is present:
# journalctl --boot | grep libapache2-mod-php7.4 | grep php7.[23] | cut -d: -f5
php7.3 module already enabled, not enabling PHP 7.4
# apt-cache policy libapache2-mod-php* | grep -B1 Installed
libapache2-mod-php:
Installed: 2:7.4+75
--
libapache2-mod-php5:
Installed: (none)
--
libapache2-mod-php7.2:
Installed: (none)
--
libapache2-mod-php7.3:
Installed: (none)
--
libapache2-mod-php7.4:
Installed: 7.4.3-4ubuntu1
To verify the fix (for bionic; eoan is similar):
$ lxc launch ubuntu:18.04/amd64 bb
$ lxc exec bb -- bash
# apt-get -y install software-properties-common
# add-apt-repository -yus ppa:bryce/php-defaults-fix-lp1865218-mod-php-upgrade
# apt-cache policy libapache2-mod-php7.2
+ Verify the new version is available
# apt-get install -y libapache2-mod-php
# apt-cache policy libapache2-mod-php7.2
+ Verify the new version is installed
# apt-get install -y ubuntu-release-upgrader-core
# apt-get upgrade -y
# do-release-upgrade -d
+ Answer defaults for everything
+ Allow it to reboot when done, and log back in
# Verify the 7.4 version is installed
apt-cache policy libapache2-mod-php* | grep -B1 Installed
# Verify error is not present
journalctl --boot | grep libapache2-mod-php7.4 | grep php7.[23] | cut -d: -f5
[Regression Potential]
Since this change affects only the installer's upgrade logic, the thing to keep an eye on would be behavioral changes during upgrades or, possibly, during installation.
Presumably the rationale for the current behavior of refusing to disable an already running mod-php is if the user had intentionally installed a non-distro managed or self-modified mod-php. Upgrading in such a situation might result in unexpected behavior changes. However, this custom configuration is unlikely to be common, and should be expected to be affected during a system upgrade.
[Original Report]
Yesterday, when upgrading a client VMs running Xenial and moving to Bionic, I noticed Apache's mod_php was disabled. I later reproduced this in a container:
# create a Xenial container
$ lxc launch images:ubuntu/xenial xa
Creating xa
Starting xa
# Install Apache mod_php
$ lxc shell xa
mesg: ttyname failed: Success
root@xa:~# apt-get install libapache2-mod-php
Reading package lists... Done
Building dependency tree
Reading state information... Done
...
Unpacking libapache2-mod-php7.0 (7.0.33-0ubuntu0.16.04.12) ...
...
apache2_switch_mpm Switch to prefork
apache2_invoke: Enable module php7.0
# Upgrade to Bionic
root@xa:~# apt-get install ubuntu-release-upgrader-core
...
root@xa:~# do-release-upgrade
...
Creating config file /etc/php/7.2/cli/php.ini with new version
Setting up libapache2-mod-php7.2 (7.2.24-0ubuntu0.18.04.3) ...
Creating config file /etc/php/7.2/apache2/php.ini with new version
libapache2-mod-php7.2: php7.0 module already enabled, not enabling PHP 7.2
Setting up libapache2-mod-php (1:7.2+60ubuntu1) ...
...
Removing libapache2-mod-php7.0 (7.0.33-0ubuntu0.16.04.12) ...
Module php7.0 disabled.
apache2_invoke prerm: Disable module php7.0
Purging configuration files for libapache2-mod-php7.0 (7.0.33-0ubuntu0.16.04.12) ...
apache2_invoke postrm: Purging state for php7.0
dpkg: warning: while removing libapache2-mod-php7.0, directory '/etc/php/7.0/apache2/conf.d' not empty so not removed
...
System upgrade is complete.
Restart required
To finish the upgrade, a restart is required.
If you select 'y' the system will be restarted.
Continue [yN] y
Additional information on the upgraded container:
root@xa:~# lsb_release -rd
Description: Ubuntu 18.04.4 LTS
Release: 18.04
root@xa:~# apt-cache policy libapache2-mod-php7.2
libapache2-mod-php7.2:
Installed: 7.2.24-0ubuntu0.18.04.3
Candidate: 7.2.24-0ubuntu0.18.04.3
Version table:
*** 7.2.24-0ubuntu0.18.04.3 500
500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages
100 /var/lib/dpkg/status
7.2.3-1ubuntu1 500
500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages |
|
| 2020-05-26 19:36:14 |
Simon Déziel |
description |
[Impact]
A normal upgrade of a properly functioning PHP website server can unexpectedly result in disabling PHP, when there are no misconfigurations or other actual errors. It's also easy to miss the error message, thus making it more challenging to notice the site breakage.
[Fix]
Instead of issuing an err when there is already one or more active apache mod for php(s) of a different version, issue a warning and disable it.
[Test Case]
For bionic -> focal upgrades:
$ lxc launch ubuntu:18.04/amd64 ba
$ lxc exec ba -- bash
# apt-get install -y libapache2-mod-php
# apt-get install -y ubuntu-release-upgrader-core
# do-release-upgrade -d
+ Answer defaults for everything
+ Allow it to reboot when done, and log back in
For eoan -> focal upgrades:
$ lxc launch ubuntu:19.10/amd64 ea
$ lxc exec ea -- bash
# apt-get install -y libapache2-mod-php
# apt-get install -y ubuntu-release-upgrader-core
# do-release-upgrade
+ Answer defaults for everything
+ Allow it to reboot when done, and log back in
For either case, to verify the error is present:
# journalctl --boot | grep libapache2-mod-php7.4 | grep php7.[23] | cut -d: -f5
php7.3 module already enabled, not enabling PHP 7.4
# apt-cache policy libapache2-mod-php* | grep -B1 Installed
libapache2-mod-php:
Installed: 2:7.4+75
--
libapache2-mod-php5:
Installed: (none)
--
libapache2-mod-php7.2:
Installed: (none)
--
libapache2-mod-php7.3:
Installed: (none)
--
libapache2-mod-php7.4:
Installed: 7.4.3-4ubuntu1
To verify the fix (for bionic; eoan is similar):
$ lxc launch ubuntu:18.04/amd64 bb
$ lxc exec bb -- bash
# apt-get -y install software-properties-common
# add-apt-repository -yus ppa:bryce/php-defaults-fix-lp1865218-mod-php-upgrade
# apt-cache policy libapache2-mod-php7.2
+ Verify the new version is available
# apt-get install -y libapache2-mod-php
# apt-cache policy libapache2-mod-php7.2
+ Verify the new version is installed
# apt-get install -y ubuntu-release-upgrader-core
# apt-get upgrade -y
# do-release-upgrade -d
+ Answer defaults for everything
+ Allow it to reboot when done, and log back in
# Verify the 7.4 version is installed
apt-cache policy libapache2-mod-php* | grep -B1 Installed
# Verify error is not present
journalctl --boot | grep libapache2-mod-php7.4 | grep php7.[23] | cut -d: -f5
[Regression Potential]
Since this change affects only the installer's upgrade logic, the thing to keep an eye on would be behavioral changes during upgrades or, possibly, during installation.
Presumably the rationale for the current behavior of refusing to disable an already running mod-php is if the user had intentionally installed a non-distro managed or self-modified mod-php. Upgrading in such a situation might result in unexpected behavior changes. However, this custom configuration is unlikely to be common, and should be expected to be affected during a system upgrade.
[Original Report]
Yesterday, when upgrading a client VMs running Xenial and moving to Bionic, I noticed Apache's mod_php was disabled. I later reproduced this in a container:
# create a Xenial container
$ lxc launch images:ubuntu/xenial xa
Creating xa
Starting xa
# Install Apache mod_php
$ lxc shell xa
mesg: ttyname failed: Success
root@xa:~# apt-get install libapache2-mod-php
Reading package lists... Done
Building dependency tree
Reading state information... Done
...
Unpacking libapache2-mod-php7.0 (7.0.33-0ubuntu0.16.04.12) ...
...
apache2_switch_mpm Switch to prefork
apache2_invoke: Enable module php7.0
# Upgrade to Bionic
root@xa:~# apt-get install ubuntu-release-upgrader-core
...
root@xa:~# do-release-upgrade
...
Creating config file /etc/php/7.2/cli/php.ini with new version
Setting up libapache2-mod-php7.2 (7.2.24-0ubuntu0.18.04.3) ...
Creating config file /etc/php/7.2/apache2/php.ini with new version
libapache2-mod-php7.2: php7.0 module already enabled, not enabling PHP 7.2
Setting up libapache2-mod-php (1:7.2+60ubuntu1) ...
...
Removing libapache2-mod-php7.0 (7.0.33-0ubuntu0.16.04.12) ...
Module php7.0 disabled.
apache2_invoke prerm: Disable module php7.0
Purging configuration files for libapache2-mod-php7.0 (7.0.33-0ubuntu0.16.04.12) ...
apache2_invoke postrm: Purging state for php7.0
dpkg: warning: while removing libapache2-mod-php7.0, directory '/etc/php/7.0/apache2/conf.d' not empty so not removed
...
System upgrade is complete.
Restart required
To finish the upgrade, a restart is required.
If you select 'y' the system will be restarted.
Continue [yN] y
Additional information on the upgraded container:
root@xa:~# lsb_release -rd
Description: Ubuntu 18.04.4 LTS
Release: 18.04
root@xa:~# apt-cache policy libapache2-mod-php7.2
libapache2-mod-php7.2:
Installed: 7.2.24-0ubuntu0.18.04.3
Candidate: 7.2.24-0ubuntu0.18.04.3
Version table:
*** 7.2.24-0ubuntu0.18.04.3 500
500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages
100 /var/lib/dpkg/status
7.2.3-1ubuntu1 500
500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages |
[Impact]
A normal upgrade of a properly functioning PHP website server can unexpectedly result in disabling PHP, when there are no misconfigurations or other actual errors. It's also easy to miss the error message, thus making it more challenging to notice the site breakage.
[Fix]
Instead of issuing an err when there is already one or more active apache mod for php(s) of a different version, issue a warning and disable it.
[Test Case]
For bionic -> focal upgrades:
$ lxc launch ubuntu:18.04/amd64 ba
$ lxc exec ba -- bash
# apt-get install -y libapache2-mod-php
# apt-get install -y ubuntu-release-upgrader-core
# do-release-upgrade -d
+ Answer defaults for everything
+ Allow it to reboot when done, and log back in
For eoan -> focal upgrades:
$ lxc launch ubuntu:19.10/amd64 ea
$ lxc exec ea -- bash
# apt-get install -y libapache2-mod-php
# apt-get install -y ubuntu-release-upgrader-core
# do-release-upgrade
+ Answer defaults for everything
+ Allow it to reboot when done, and log back in
For either case, to verify the error is present:
# journalctl --boot | grep libapache2-mod-php7.4 | grep php7.[23] | cut -d: -f5
php7.3 module already enabled, not enabling PHP 7.4
# apt-cache policy libapache2-mod-php* | grep -B1 Installed
libapache2-mod-php:
Installed: 2:7.4+75
--
libapache2-mod-php5:
Installed: (none)
--
libapache2-mod-php7.2:
Installed: (none)
--
libapache2-mod-php7.3:
Installed: (none)
--
libapache2-mod-php7.4:
Installed: 7.4.3-4ubuntu1
To verify the fix (for bionic; eoan is similar: s/7.2/7.3/):
$ lxc launch ubuntu:18.04/amd64 bb
$ lxc exec bb -- bash
# apt-get -y install software-properties-common
# add-apt-repository -yus ppa:bryce/php-defaults-fix-lp1865218-mod-php-upgrade
# apt-cache policy libapache2-mod-php7.2
+ Verify the new version is available
# apt-get install -y libapache2-mod-php7.2
# apt-cache policy libapache2-mod-php7.2
+ Verify the new version is installed
# apt-get install -y ubuntu-release-upgrader-core
# apt-get upgrade -y
# do-release-upgrade -d # drop -d on eoan
+ Answer defaults for everything
+ Allow it to reboot when done, and log back in
# Verify the 7.4 version is installed
apt-cache policy libapache2-mod-php* | grep -B1 Installed
# Verify error is not present
journalctl --boot | grep libapache2-mod-php7.4 | grep php7.[23] | cut -d: -f5
[Regression Potential]
Since this change affects only the installer's upgrade logic, the thing to keep an eye on would be behavioral changes during upgrades or, possibly, during installation.
Presumably the rationale for the current behavior of refusing to disable an already running mod-php is if the user had intentionally installed a non-distro managed or self-modified mod-php. Upgrading in such a situation might result in unexpected behavior changes. However, this custom configuration is unlikely to be common, and should be expected to be affected during a system upgrade.
[Original Report]
Yesterday, when upgrading a client VMs running Xenial and moving to Bionic, I noticed Apache's mod_php was disabled. I later reproduced this in a container:
# create a Xenial container
$ lxc launch images:ubuntu/xenial xa
Creating xa
Starting xa
# Install Apache mod_php
$ lxc shell xa
mesg: ttyname failed: Success
root@xa:~# apt-get install libapache2-mod-php
Reading package lists... Done
Building dependency tree
Reading state information... Done
...
Unpacking libapache2-mod-php7.0 (7.0.33-0ubuntu0.16.04.12) ...
...
apache2_switch_mpm Switch to prefork
apache2_invoke: Enable module php7.0
# Upgrade to Bionic
root@xa:~# apt-get install ubuntu-release-upgrader-core
...
root@xa:~# do-release-upgrade
...
Creating config file /etc/php/7.2/cli/php.ini with new version
Setting up libapache2-mod-php7.2 (7.2.24-0ubuntu0.18.04.3) ...
Creating config file /etc/php/7.2/apache2/php.ini with new version
libapache2-mod-php7.2: php7.0 module already enabled, not enabling PHP 7.2
Setting up libapache2-mod-php (1:7.2+60ubuntu1) ...
...
Removing libapache2-mod-php7.0 (7.0.33-0ubuntu0.16.04.12) ...
Module php7.0 disabled.
apache2_invoke prerm: Disable module php7.0
Purging configuration files for libapache2-mod-php7.0 (7.0.33-0ubuntu0.16.04.12) ...
apache2_invoke postrm: Purging state for php7.0
dpkg: warning: while removing libapache2-mod-php7.0, directory '/etc/php/7.0/apache2/conf.d' not empty so not removed
...
System upgrade is complete.
Restart required
To finish the upgrade, a restart is required.
If you select 'y' the system will be restarted.
Continue [yN] y
Additional information on the upgraded container:
root@xa:~# lsb_release -rd
Description: Ubuntu 18.04.4 LTS
Release: 18.04
root@xa:~# apt-cache policy libapache2-mod-php7.2
libapache2-mod-php7.2:
Installed: 7.2.24-0ubuntu0.18.04.3
Candidate: 7.2.24-0ubuntu0.18.04.3
Version table:
*** 7.2.24-0ubuntu0.18.04.3 500
500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages
100 /var/lib/dpkg/status
7.2.3-1ubuntu1 500
500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages |
|
| 2020-05-27 18:07:55 |
Launchpad Janitor |
php7.2 (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2020-05-27 18:07:55 |
Launchpad Janitor |
cve linked |
|
2019-11048 |
|
| 2020-05-27 18:08:03 |
Launchpad Janitor |
php7.3 (Ubuntu Eoan): status |
Fix Committed |
Fix Released |
|
| 2020-05-27 18:08:05 |
Launchpad Janitor |
php7.4 (Ubuntu Focal): status |
Fix Committed |
Fix Released |
|
| 2020-05-27 21:33:56 |
Bryce Harrington |
tags |
verification-needed verification-needed-bionic verification-needed-eoan verification-needed-focal |
verification-done verification-done-bionic verification-done-eoan verification-done-focal |
|
