| 2020-12-14 10:25:23 |
Iain Lane |
bug |
|
|
added bug |
| 2020-12-14 10:25:47 |
Iain Lane |
nominated for series |
|
Ubuntu Focal |
|
| 2020-12-14 10:25:47 |
Iain Lane |
bug task added |
|
update-manager (Ubuntu Focal) |
|
| 2020-12-14 10:29:58 |
Iain Lane |
description |
[ Description ]
The Ubuntu installer (ubiquity), working together with ubuntu-drivers, will install an "OEM metapackage" for the platform being installed, if there is one which matches.
This means that if Canonical has performed enablement for a device, users will receive the same experience if they purchase hardware with Ubuntu preinstalled or if it has another OS and they later install Ubuntu.
However, if the hardware was enabled post-release and the user is offline when installing Ubuntu, the installer will not know that there is any enablement that it should install. Similarly if the enablement happens after Ubuntu has been installed. In these cases we need a way inside the installed session for the same enablement to be provided.
We're adding the capability for update-manager to install these packages. They themselves install a sources.list.d snippet referring to an "OEM archive" specific to the device, so update-manager needs to know to update (as in `apt update`) and then upgrade (`apt upgrade`) a second time after installing oem-foo-meta from the Ubuntu archive.
update-manager will be consuming a file provided by update-notifier to know if the device needs an oem metapackage or not.
[ QA ]
= On a certified device =
1. Install without any OEM enablement. Run update-notifier to populate the file $XDG_RUNTIME_DIR/ubuntu-drivers-oem.package-list. Run update-manager and make sure the OEM experience is installed properly - you end up with the version of oem-foo-meta from the OEM archive.
2. As above but with some other regular (SRU) updates available. Make sure all updates are installed.
3. After installing the OEM experience, make sure further updates are offered as normal.
= On a non certified device =
1. Make sure that updates are offered whenever they are available.
2. Make sure update-manager is launched automatically (by update-notifier) as before.
[ What could go wrong ]
In this update we rework transaction handling. If this is wrong, then the progress bar or terminal could stop working.
If there's a bug in the way we install / update / upgrade the OEM metapackages then we could break installing any update.
If we accidentally apply this logic to non OEM systems then we could break updating for everybody. |
[ Description ]
The Ubuntu installer (ubiquity), working together with ubuntu-drivers, will install an "OEM metapackage" for the platform being installed, if there is one which matches.
This means that if Canonical has performed enablement for a device, users will receive the same experience if they purchase hardware with Ubuntu preinstalled or if it has another OS and they later install Ubuntu.
However, if the hardware was enabled post-release and the user is offline when installing Ubuntu, the installer will not know that there is any enablement that it should install. Similarly if the enablement happens after Ubuntu has been installed. In these cases we need a way inside the installed session for the same enablement to be provided.
We're adding the capability for update-manager to install these packages. They themselves install a sources.list.d snippet referring to an "OEM archive" specific to the device, so update-manager needs to know to update (as in `apt update`) and then upgrade (`apt upgrade`) a second time after installing oem-foo-meta from the Ubuntu archive.
update-manager will be consuming a file provided by update-notifier to know if the device needs an oem metapackage or not.
NOTE NOTE NOTE NOTE NOTE NOTE: The OEM metapackages are LTS only, so the intention is that this change is effectively a no-op on hirsute. Therefore we are proposing NOT to SRU to groovy, as there is no chance of a regression for groovy users.
[ QA ]
= On a certified device =
1. Install without any OEM enablement. Run update-notifier to populate the file $XDG_RUNTIME_DIR/ubuntu-drivers-oem.package-list. Run update-manager and make sure the OEM experience is installed properly - you end up with the version of oem-foo-meta from the OEM archive.
2. As above but with some other regular (SRU) updates available. Make sure all updates are installed.
3. After installing the OEM experience, make sure further updates are offered as normal.
= On a non certified device =
1. Make sure that updates are offered whenever they are available.
2. Make sure update-manager is launched automatically (by update-notifier) as before.
[ What could go wrong ]
In this update we rework transaction handling. If this is wrong, then the progress bar or terminal could stop working.
If there's a bug in the way we install / update / upgrade the OEM metapackages then we could break installing any update.
If we accidentally apply this logic to non OEM systems then we could break updating for everybody. |
|
| 2020-12-14 10:31:34 |
Iain Lane |
bug task added |
|
update-notifier (Ubuntu) |
|
| 2020-12-14 10:31:47 |
Iain Lane |
update-notifier (Ubuntu): assignee |
|
Iain Lane (laney) |
|
| 2020-12-14 10:31:48 |
Iain Lane |
update-notifier (Ubuntu Focal): assignee |
|
Iain Lane (laney) |
|
| 2020-12-14 10:32:15 |
Rex Tsai |
bug |
|
|
added subscriber Rex Tsai |
| 2020-12-14 10:32:16 |
Iain Lane |
update-manager (Ubuntu): assignee |
|
Julian Andres Klode (juliank) |
|
| 2020-12-14 10:32:21 |
Iain Lane |
update-manager (Ubuntu Focal): assignee |
|
Julian Andres Klode (juliank) |
|
| 2020-12-14 10:33:26 |
Launchpad Janitor |
branch linked |
|
lp:update-manager |
|
| 2020-12-14 11:36:27 |
Iain Lane |
update-notifier (Ubuntu Focal): status |
New |
In Progress |
|
| 2020-12-14 11:36:29 |
Iain Lane |
update-notifier (Ubuntu): status |
New |
Fix Released |
|
| 2020-12-14 11:36:32 |
Iain Lane |
update-manager (Ubuntu Focal): status |
New |
In Progress |
|
| 2020-12-14 11:36:34 |
Iain Lane |
update-manager (Ubuntu): status |
New |
Fix Committed |
|
| 2020-12-15 10:31:19 |
Launchpad Janitor |
update-manager (Ubuntu): status |
Fix Committed |
Fix Released |
|
| 2020-12-18 11:16:23 |
Timo Aaltonen |
update-manager (Ubuntu Focal): status |
In Progress |
Fix Committed |
|
| 2020-12-18 11:16:25 |
Timo Aaltonen |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2020-12-18 11:16:27 |
Timo Aaltonen |
bug |
|
|
added subscriber SRU Verification |
| 2020-12-18 11:16:31 |
Timo Aaltonen |
tags |
|
verification-needed verification-needed-focal |
|
| 2020-12-23 08:38:28 |
Shih-Yuan Lee |
bug |
|
|
added subscriber Shih-Yuan Lee |
| 2021-01-06 10:11:14 |
Timo Aaltonen |
update-notifier (Ubuntu Focal): status |
In Progress |
Fix Committed |
|
| 2021-01-07 08:08:16 |
Shih-Yuan Lee |
tags |
verification-needed verification-needed-focal |
verification-failed verification-failed-focal |
|
| 2021-01-07 08:27:18 |
Julian Andres Klode |
tags |
verification-failed verification-failed-focal |
verification-needed verification-needed-focal |
|
| 2021-01-07 09:12:58 |
Shih-Yuan Lee |
description |
[ Description ]
The Ubuntu installer (ubiquity), working together with ubuntu-drivers, will install an "OEM metapackage" for the platform being installed, if there is one which matches.
This means that if Canonical has performed enablement for a device, users will receive the same experience if they purchase hardware with Ubuntu preinstalled or if it has another OS and they later install Ubuntu.
However, if the hardware was enabled post-release and the user is offline when installing Ubuntu, the installer will not know that there is any enablement that it should install. Similarly if the enablement happens after Ubuntu has been installed. In these cases we need a way inside the installed session for the same enablement to be provided.
We're adding the capability for update-manager to install these packages. They themselves install a sources.list.d snippet referring to an "OEM archive" specific to the device, so update-manager needs to know to update (as in `apt update`) and then upgrade (`apt upgrade`) a second time after installing oem-foo-meta from the Ubuntu archive.
update-manager will be consuming a file provided by update-notifier to know if the device needs an oem metapackage or not.
NOTE NOTE NOTE NOTE NOTE NOTE: The OEM metapackages are LTS only, so the intention is that this change is effectively a no-op on hirsute. Therefore we are proposing NOT to SRU to groovy, as there is no chance of a regression for groovy users.
[ QA ]
= On a certified device =
1. Install without any OEM enablement. Run update-notifier to populate the file $XDG_RUNTIME_DIR/ubuntu-drivers-oem.package-list. Run update-manager and make sure the OEM experience is installed properly - you end up with the version of oem-foo-meta from the OEM archive.
2. As above but with some other regular (SRU) updates available. Make sure all updates are installed.
3. After installing the OEM experience, make sure further updates are offered as normal.
= On a non certified device =
1. Make sure that updates are offered whenever they are available.
2. Make sure update-manager is launched automatically (by update-notifier) as before.
[ What could go wrong ]
In this update we rework transaction handling. If this is wrong, then the progress bar or terminal could stop working.
If there's a bug in the way we install / update / upgrade the OEM metapackages then we could break installing any update.
If we accidentally apply this logic to non OEM systems then we could break updating for everybody. |
[ Description ]
The Ubuntu installer (ubiquity), working together with ubuntu-drivers, will install an "OEM metapackage" for the platform being installed, if there is one which matches.
This means that if Canonical has performed enablement for a device, users will receive the same experience if they purchase hardware with Ubuntu preinstalled or if it has another OS and they later install Ubuntu.
However, if the hardware was enabled post-release and the user is offline when installing Ubuntu, the installer will not know that there is any enablement that it should install. Similarly if the enablement happens after Ubuntu has been installed. In these cases we need a way inside the installed session for the same enablement to be provided.
We're adding the capability for update-manager to install these packages. They themselves install a sources.list.d snippet referring to an "OEM archive" specific to the device, so update-manager needs to know to update (as in `apt update`) and then upgrade (`apt upgrade`) a second time after installing oem-foo-meta from the Ubuntu archive.
update-manager will be consuming a file provided by update-notifier to know if the device needs an oem metapackage or not.
NOTE NOTE NOTE NOTE NOTE NOTE: The OEM metapackages are LTS only, so the intention is that this change is effectively a no-op on hirsute. Therefore we are proposing NOT to SRU to groovy, as there is no chance of a regression for groovy users.
[ QA ]
= On a certified device =
1. Update the system to the latest without focal-proposed.
2. Enable focal-proposed, and then only install update-manager/1:20.04.10.2 and update-notifier/3.192.30.4 from focal-proposed.
3. Reboot the system and wait for a while.
The notification will pop up and we can see "Improved hardware support" on the certified machines.
= On a non certified device =
1. Make sure that updates are offered whenever they are available.
2. Make sure update-manager is launched automatically (by update-notifier) as before.
[ What could go wrong ]
In this update we rework transaction handling. If this is wrong, then the progress bar or terminal could stop working.
If there's a bug in the way we install / update / upgrade the OEM metapackages then we could break installing any update.
If we accidentally apply this logic to non OEM systems then we could break updating for everybody. |
|
| 2021-01-07 09:13:31 |
Shih-Yuan Lee |
description |
[ Description ]
The Ubuntu installer (ubiquity), working together with ubuntu-drivers, will install an "OEM metapackage" for the platform being installed, if there is one which matches.
This means that if Canonical has performed enablement for a device, users will receive the same experience if they purchase hardware with Ubuntu preinstalled or if it has another OS and they later install Ubuntu.
However, if the hardware was enabled post-release and the user is offline when installing Ubuntu, the installer will not know that there is any enablement that it should install. Similarly if the enablement happens after Ubuntu has been installed. In these cases we need a way inside the installed session for the same enablement to be provided.
We're adding the capability for update-manager to install these packages. They themselves install a sources.list.d snippet referring to an "OEM archive" specific to the device, so update-manager needs to know to update (as in `apt update`) and then upgrade (`apt upgrade`) a second time after installing oem-foo-meta from the Ubuntu archive.
update-manager will be consuming a file provided by update-notifier to know if the device needs an oem metapackage or not.
NOTE NOTE NOTE NOTE NOTE NOTE: The OEM metapackages are LTS only, so the intention is that this change is effectively a no-op on hirsute. Therefore we are proposing NOT to SRU to groovy, as there is no chance of a regression for groovy users.
[ QA ]
= On a certified device =
1. Update the system to the latest without focal-proposed.
2. Enable focal-proposed, and then only install update-manager/1:20.04.10.2 and update-notifier/3.192.30.4 from focal-proposed.
3. Reboot the system and wait for a while.
The notification will pop up and we can see "Improved hardware support" on the certified machines.
= On a non certified device =
1. Make sure that updates are offered whenever they are available.
2. Make sure update-manager is launched automatically (by update-notifier) as before.
[ What could go wrong ]
In this update we rework transaction handling. If this is wrong, then the progress bar or terminal could stop working.
If there's a bug in the way we install / update / upgrade the OEM metapackages then we could break installing any update.
If we accidentally apply this logic to non OEM systems then we could break updating for everybody. |
[ Description ]
The Ubuntu installer (ubiquity), working together with ubuntu-drivers, will install an "OEM metapackage" for the platform being installed, if there is one which matches.
This means that if Canonical has performed enablement for a device, users will receive the same experience if they purchase hardware with Ubuntu preinstalled or if it has another OS and they later install Ubuntu.
However, if the hardware was enabled post-release and the user is offline when installing Ubuntu, the installer will not know that there is any enablement that it should install. Similarly if the enablement happens after Ubuntu has been installed. In these cases we need a way inside the installed session for the same enablement to be provided.
We're adding the capability for update-manager to install these packages. They themselves install a sources.list.d snippet referring to an "OEM archive" specific to the device, so update-manager needs to know to update (as in `apt update`) and then upgrade (`apt upgrade`) a second time after installing oem-foo-meta from the Ubuntu archive.
update-manager will be consuming a file provided by update-notifier to know if the device needs an oem metapackage or not.
NOTE NOTE NOTE NOTE NOTE NOTE: The OEM metapackages are LTS only, so the intention is that this change is effectively a no-op on hirsute. Therefore we are proposing NOT to SRU to groovy, as there is no chance of a regression for groovy users.
[ QA ]
= On a certified device =
1. Update the system to the latest without focal-proposed.
2. Enable focal-proposed, and then only install update-manager/1:20.04.10.2 and update-notifier/3.192.30.4 from focal-proposed.
3. Reboot the system, login the desktop and wait for a while.
The notification will pop up and we can see "Improved hardware support" on the certified machines.
= On a non certified device =
1. Make sure that updates are offered whenever they are available.
2. Make sure update-manager is launched automatically (by update-notifier) as before.
[ What could go wrong ]
In this update we rework transaction handling. If this is wrong, then the progress bar or terminal could stop working.
If there's a bug in the way we install / update / upgrade the OEM metapackages then we could break installing any update.
If we accidentally apply this logic to non OEM systems then we could break updating for everybody. |
|
| 2021-01-07 09:14:33 |
Shih-Yuan Lee |
attachment added |
|
update-manager.png https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1908050/+attachment/5450090/+files/update-manager.png |
|
| 2021-01-07 13:35:37 |
Shih-Yuan Lee |
description |
[ Description ]
The Ubuntu installer (ubiquity), working together with ubuntu-drivers, will install an "OEM metapackage" for the platform being installed, if there is one which matches.
This means that if Canonical has performed enablement for a device, users will receive the same experience if they purchase hardware with Ubuntu preinstalled or if it has another OS and they later install Ubuntu.
However, if the hardware was enabled post-release and the user is offline when installing Ubuntu, the installer will not know that there is any enablement that it should install. Similarly if the enablement happens after Ubuntu has been installed. In these cases we need a way inside the installed session for the same enablement to be provided.
We're adding the capability for update-manager to install these packages. They themselves install a sources.list.d snippet referring to an "OEM archive" specific to the device, so update-manager needs to know to update (as in `apt update`) and then upgrade (`apt upgrade`) a second time after installing oem-foo-meta from the Ubuntu archive.
update-manager will be consuming a file provided by update-notifier to know if the device needs an oem metapackage or not.
NOTE NOTE NOTE NOTE NOTE NOTE: The OEM metapackages are LTS only, so the intention is that this change is effectively a no-op on hirsute. Therefore we are proposing NOT to SRU to groovy, as there is no chance of a regression for groovy users.
[ QA ]
= On a certified device =
1. Update the system to the latest without focal-proposed.
2. Enable focal-proposed, and then only install update-manager/1:20.04.10.2 and update-notifier/3.192.30.4 from focal-proposed.
3. Reboot the system, login the desktop and wait for a while.
The notification will pop up and we can see "Improved hardware support" on the certified machines.
= On a non certified device =
1. Make sure that updates are offered whenever they are available.
2. Make sure update-manager is launched automatically (by update-notifier) as before.
[ What could go wrong ]
In this update we rework transaction handling. If this is wrong, then the progress bar or terminal could stop working.
If there's a bug in the way we install / update / upgrade the OEM metapackages then we could break installing any update.
If we accidentally apply this logic to non OEM systems then we could break updating for everybody. |
[ Description ]
The Ubuntu installer (ubiquity), working together with ubuntu-drivers, will install an "OEM metapackage" for the platform being installed, if there is one which matches.
This means that if Canonical has performed enablement for a device, users will receive the same experience if they purchase hardware with Ubuntu preinstalled or if it has another OS and they later install Ubuntu.
However, if the hardware was enabled post-release and the user is offline when installing Ubuntu, the installer will not know that there is any enablement that it should install. Similarly if the enablement happens after Ubuntu has been installed. In these cases we need a way inside the installed session for the same enablement to be provided.
We're adding the capability for update-manager to install these packages. They themselves install a sources.list.d snippet referring to an "OEM archive" specific to the device, so update-manager needs to know to update (as in `apt update`) and then upgrade (`apt upgrade`) a second time after installing oem-foo-meta from the Ubuntu archive.
update-manager will be consuming a file provided by update-notifier to know if the device needs an oem metapackage or not.
NOTE NOTE NOTE NOTE NOTE NOTE: The OEM metapackages are LTS only, so the intention is that this change is effectively a no-op on hirsute. Therefore we are proposing NOT to SRU to groovy, as there is no chance of a regression for groovy users.
[ QA ]
= On a certified device =
1. Update the system to the latest without focal-proposed.
2. Enable focal-proposed, and then only install update-manager/1:20.04.10.2 and update-notifier/3.192.30.4 from focal-proposed.
3. Reboot the system, login the desktop and wait for a while.
The notification will pop up and it will show "Improved hardware support" on the certified machines that has the OEM metapackage support.
= On a non certified device =
1. Update the system to the latest without focal-proposed.
2. Enable focal-proposed, and then only install update-manager/1:20.04.10.2 and update-notifier/3.192.30.4 from focal-proposed.
3. Reboot the system, login the desktop and wait for a while.
The notification will pop up but it won't show "Improved hardware support" on non certified machines.
[ What could go wrong ]
In this update we rework transaction handling. If this is wrong, then the progress bar or terminal could stop working.
If there's a bug in the way we install / update / upgrade the OEM metapackages then we could break installing any update.
If we accidentally apply this logic to non OEM systems then we could break updating for everybody. |
|
| 2021-01-07 15:36:07 |
Shih-Yuan Lee |
attachment added |
|
Dell_XPS_13_9300.png https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1908050/+attachment/5450295/+files/Dell_XPS_13_9300.png |
|
| 2021-01-07 15:36:18 |
Shih-Yuan Lee |
attachment removed |
update-manager.png https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1908050/+attachment/5450090/+files/update-manager.png |
|
|
| 2021-01-07 16:29:18 |
Shih-Yuan Lee |
attachment added |
|
Dell_Inspiron_5391.png https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1908050/+attachment/5450316/+files/Dell_Inspiron_5391.png |
|
| 2021-01-07 16:33:25 |
Shih-Yuan Lee |
attachment added |
|
Screenshot from 2021-01-07 11-26-46.png https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1908050/+attachment/5450317/+files/Screenshot%20from%202021-01-07%2011-26-46.png |
|
| 2021-01-07 16:34:19 |
Shih-Yuan Lee |
attachment added |
|
_usr_bin_update-manager.1000.crash https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1908050/+attachment/5450318/+files/_usr_bin_update-manager.1000.crash |
|
| 2021-01-19 02:54:10 |
Shih-Yuan Lee |
tags |
verification-needed verification-needed-focal |
verification-done verification-done-focal |
|
| 2021-01-19 16:46:44 |
Launchpad Janitor |
update-notifier (Ubuntu Focal): status |
Fix Committed |
Fix Released |
|
| 2021-01-19 16:46:49 |
Brian Murray |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2021-01-21 16:30:55 |
Launchpad Janitor |
update-manager (Ubuntu Focal): status |
Fix Committed |
Fix Released |
|
| 2021-01-22 01:03:36 |
Brian Murray |
bug |
|
|
added subscriber Brian Murray |
