| 2024-02-16 14:18:55 |
Utkarsh Gupta |
bug |
|
|
added bug |
| 2024-02-16 15:38:37 |
Andrew Cloke |
bug |
|
|
added subscriber Andrew Cloke |
| 2024-02-22 13:30:37 |
Utkarsh Gupta |
description |
TBW.. |
grub-pc requires knowing what device to grub-install on, but when cloud images are generated, the device on the deployment target is never known. And so when the package is reinstalled (for example, when unminimizing the minimized image), the user gets that prompt, asking where to install the grub, when this should happen non-interactively, for example, by determining where the grub was first installed.
Interestingly, this issue always existed, however it was masked by the following timeline:
In July 2020, it was discovered that certain scenarios can cause grub-pc installation to fail, and an emergency SRU https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1889556 disabled grub-pc re-installation on upgrade as a workaround.
Before the commit https://salsa.debian.org/grub-team/grub/-/commit/8d809abe752712cb020e2e95fe21d5832bea52f8 got merged into Ubuntu, grub-pc/install-devices being unset in debconf was acceptable in practice. This was indeed unset and still is for cloud images.
In Dec 2021, grub2 2.06-2ubuntu1 was uploaded containing the previously mentioned commit. But as a result of the above emergency SRU, that upload managed to silently change the status quo without it ever being noticed.
In December 2023, the grub-pc installation workaround was finally removed in https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/2043995 exposing grub-pc package upgrade failures in cloud images where grub-pc/install-devices in debconf was never in-fact set.
The plausible solution is to develop something to set the grub-pc/install-devices debconf entry on first boot in a cloud deployment, which would allow upgrades to function like before. |
|
| 2024-02-22 13:32:11 |
Utkarsh Gupta |
bug task added |
|
grub2 (Ubuntu) |
|
| 2024-02-22 15:51:57 |
Mate Kukri |
bug task added |
|
ubuntu-release-upgrader (Ubuntu) |
|
| 2024-02-22 18:03:06 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~philroche/livecd-rootfs/+git/livecd-rootfs/+merge/461062 |
|
| 2024-02-27 17:58:20 |
Launchpad Janitor |
grub2 (Ubuntu): status |
New |
Fix Released |
|
| 2024-03-07 09:44:38 |
Mate Kukri |
tags |
|
foundations-todo |
|
| 2024-03-29 22:47:38 |
Utkarsh Gupta |
cloud-images: status |
New |
Fix Released |
|
| 2024-03-29 22:47:49 |
Utkarsh Gupta |
cloud-images: assignee |
|
Utkarsh Gupta (utkarsh) |
|
| 2024-07-01 07:13:54 |
Mate Kukri |
ubuntu-release-upgrader (Ubuntu): assignee |
|
Mate Kukri (mkukri) |
|
| 2024-07-01 14:22:20 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~mkukri/ubuntu-release-upgrader/+git/ubuntu-release-upgrader-1/+merge/468504 |
|
| 2024-07-12 17:03:57 |
Mate Kukri |
description |
grub-pc requires knowing what device to grub-install on, but when cloud images are generated, the device on the deployment target is never known. And so when the package is reinstalled (for example, when unminimizing the minimized image), the user gets that prompt, asking where to install the grub, when this should happen non-interactively, for example, by determining where the grub was first installed.
Interestingly, this issue always existed, however it was masked by the following timeline:
In July 2020, it was discovered that certain scenarios can cause grub-pc installation to fail, and an emergency SRU https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1889556 disabled grub-pc re-installation on upgrade as a workaround.
Before the commit https://salsa.debian.org/grub-team/grub/-/commit/8d809abe752712cb020e2e95fe21d5832bea52f8 got merged into Ubuntu, grub-pc/install-devices being unset in debconf was acceptable in practice. This was indeed unset and still is for cloud images.
In Dec 2021, grub2 2.06-2ubuntu1 was uploaded containing the previously mentioned commit. But as a result of the above emergency SRU, that upload managed to silently change the status quo without it ever being noticed.
In December 2023, the grub-pc installation workaround was finally removed in https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/2043995 exposing grub-pc package upgrade failures in cloud images where grub-pc/install-devices in debconf was never in-fact set.
The plausible solution is to develop something to set the grub-pc/install-devices debconf entry on first boot in a cloud deployment, which would allow upgrades to function like before. |
[ Impact ]
* We have changed GRUB2 packaging to have two installation modes,
"cloud style", and default.
* The cloud style one should be used, and is used by cloud images
starting with Noble.
* Pre-noble cloud images don't have this option set, thus the need
for an u-r-u quirk to set it on upgrade.
[ Test Plan ]
* Test upgrading Jammy -> Noble on a non-cloud install, ensure the debconf
option *is not set* afterwards.
* Test upgrading Jammy -> Noble on a cloud install, ensure the debconf
option *is set* afterwards.
* Note that this was already verified, so this task is about re-verification
after the updated u-r-u is in noble-proposed.
[ Where problems could occur ]
* This SRU is only about the release upgrader change, thus impact is
limited to upgrades to Noble.
* If an installation that cannot use the cloud mechanism in GRUB has
'/etc/cloud/build.info' present, it could cause grub2 postinst to fail.
* This is rather unlikely, but a theoretically possible scenario.
[ Other Info ]
* See the original bug description below.
================================================================================
grub-pc requires knowing what device to grub-install on, but when cloud images are generated, the device on the deployment target is never known. And so when the package is reinstalled (for example, when unminimizing the minimized image), the user gets that prompt, asking where to install the grub, when this should happen non-interactively, for example, by determining where the grub was first installed.
Interestingly, this issue always existed, however it was masked by the following timeline:
In July 2020, it was discovered that certain scenarios can cause grub-pc installation to fail, and an emergency SRU https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1889556 disabled grub-pc re-installation on upgrade as a workaround.
Before the commit https://salsa.debian.org/grub-team/grub/-/commit/8d809abe752712cb020e2e95fe21d5832bea52f8 got merged into Ubuntu, grub-pc/install-devices being unset in debconf was acceptable in practice. This was indeed unset and still is for cloud images.
In Dec 2021, grub2 2.06-2ubuntu1 was uploaded containing the previously mentioned commit. But as a result of the above emergency SRU, that upload managed to silently change the status quo without it ever being noticed.
In December 2023, the grub-pc installation workaround was finally removed in https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/2043995 exposing grub-pc package upgrade failures in cloud images where grub-pc/install-devices in debconf was never in-fact set.
The plausible solution is to develop something to set the grub-pc/install-devices debconf entry on first boot in a cloud deployment, which would allow upgrades to function like before. |
|
| 2024-07-12 17:10:03 |
Mate Kukri |
description |
[ Impact ]
* We have changed GRUB2 packaging to have two installation modes,
"cloud style", and default.
* The cloud style one should be used, and is used by cloud images
starting with Noble.
* Pre-noble cloud images don't have this option set, thus the need
for an u-r-u quirk to set it on upgrade.
[ Test Plan ]
* Test upgrading Jammy -> Noble on a non-cloud install, ensure the debconf
option *is not set* afterwards.
* Test upgrading Jammy -> Noble on a cloud install, ensure the debconf
option *is set* afterwards.
* Note that this was already verified, so this task is about re-verification
after the updated u-r-u is in noble-proposed.
[ Where problems could occur ]
* This SRU is only about the release upgrader change, thus impact is
limited to upgrades to Noble.
* If an installation that cannot use the cloud mechanism in GRUB has
'/etc/cloud/build.info' present, it could cause grub2 postinst to fail.
* This is rather unlikely, but a theoretically possible scenario.
[ Other Info ]
* See the original bug description below.
================================================================================
grub-pc requires knowing what device to grub-install on, but when cloud images are generated, the device on the deployment target is never known. And so when the package is reinstalled (for example, when unminimizing the minimized image), the user gets that prompt, asking where to install the grub, when this should happen non-interactively, for example, by determining where the grub was first installed.
Interestingly, this issue always existed, however it was masked by the following timeline:
In July 2020, it was discovered that certain scenarios can cause grub-pc installation to fail, and an emergency SRU https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1889556 disabled grub-pc re-installation on upgrade as a workaround.
Before the commit https://salsa.debian.org/grub-team/grub/-/commit/8d809abe752712cb020e2e95fe21d5832bea52f8 got merged into Ubuntu, grub-pc/install-devices being unset in debconf was acceptable in practice. This was indeed unset and still is for cloud images.
In Dec 2021, grub2 2.06-2ubuntu1 was uploaded containing the previously mentioned commit. But as a result of the above emergency SRU, that upload managed to silently change the status quo without it ever being noticed.
In December 2023, the grub-pc installation workaround was finally removed in https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/2043995 exposing grub-pc package upgrade failures in cloud images where grub-pc/install-devices in debconf was never in-fact set.
The plausible solution is to develop something to set the grub-pc/install-devices debconf entry on first boot in a cloud deployment, which would allow upgrades to function like before. |
[ Impact ]
* We have changed GRUB2 packaging to have two installation modes,
"cloud style", and default.
* The cloud style one should be used, and is used by cloud images
starting with Noble.
* Pre-noble cloud images don't have this option set, thus the need
for an u-r-u quirk to set it on upgrade.
[ Test Plan ]
* Use debconf-show grub-pc, and look for grub-{pc,efi}/cloud_style_installation
* Test upgrading Jammy -> Noble on a non-cloud install (e.g. installed from an
ISO), ensure the debconf option *is not set* afterwards.
* Test upgrading Jammy -> Noble on a cloud install (e.g. a system deployed from
a jammy cloud image), ensure the debconf option *is set* afterwards.
* Note that this was already verified, so this task is about re-verification
after the updated u-r-u is in noble-proposed.
[ Where problems could occur ]
* This SRU is only about the release upgrader change, thus impact is
limited to upgrades to Noble.
* If an installation that cannot use the cloud mechanism in GRUB has
'/etc/cloud/build.info' present, it could cause grub2 postinst to fail.
* This is rather unlikely, but a theoretically possible scenario.
[ Other Info ]
* See the original bug description below.
================================================================================
grub-pc requires knowing what device to grub-install on, but when cloud images are generated, the device on the deployment target is never known. And so when the package is reinstalled (for example, when unminimizing the minimized image), the user gets that prompt, asking where to install the grub, when this should happen non-interactively, for example, by determining where the grub was first installed.
Interestingly, this issue always existed, however it was masked by the following timeline:
In July 2020, it was discovered that certain scenarios can cause grub-pc installation to fail, and an emergency SRU https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1889556 disabled grub-pc re-installation on upgrade as a workaround.
Before the commit https://salsa.debian.org/grub-team/grub/-/commit/8d809abe752712cb020e2e95fe21d5832bea52f8 got merged into Ubuntu, grub-pc/install-devices being unset in debconf was acceptable in practice. This was indeed unset and still is for cloud images.
In Dec 2021, grub2 2.06-2ubuntu1 was uploaded containing the previously mentioned commit. But as a result of the above emergency SRU, that upload managed to silently change the status quo without it ever being noticed.
In December 2023, the grub-pc installation workaround was finally removed in https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/2043995 exposing grub-pc package upgrade failures in cloud images where grub-pc/install-devices in debconf was never in-fact set.
The plausible solution is to develop something to set the grub-pc/install-devices debconf entry on first boot in a cloud deployment, which would allow upgrades to function like before. |
|
| 2024-07-16 18:01:35 |
Nick Rosbrook |
nominated for series |
|
Ubuntu Noble |
|
| 2024-07-16 18:01:35 |
Nick Rosbrook |
bug task added |
|
grub2 (Ubuntu Noble) |
|
| 2024-07-16 18:01:35 |
Nick Rosbrook |
bug task added |
|
ubuntu-release-upgrader (Ubuntu Noble) |
|
| 2024-07-16 18:01:56 |
Nick Rosbrook |
ubuntu-release-upgrader (Ubuntu): status |
New |
Invalid |
|
| 2024-07-16 18:02:00 |
Nick Rosbrook |
ubuntu-release-upgrader (Ubuntu Noble): status |
New |
In Progress |
|
| 2024-07-29 15:42:08 |
Łukasz Zemczak |
ubuntu-release-upgrader (Ubuntu Noble): status |
In Progress |
Fix Committed |
|
| 2024-07-29 15:42:09 |
Łukasz Zemczak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2024-07-29 15:42:15 |
Łukasz Zemczak |
bug |
|
|
added subscriber SRU Verification |
| 2024-07-29 15:42:25 |
Łukasz Zemczak |
tags |
foundations-todo |
foundations-todo verification-needed verification-needed-noble |
|
| 2024-08-02 15:51:07 |
Mate Kukri |
tags |
foundations-todo verification-needed verification-needed-noble |
foundations-todo verification-done verification-done-noble |
|
| 2024-08-12 11:06:23 |
Łukasz Zemczak |
tags |
foundations-todo verification-done verification-done-noble |
foundations-todo verification-needed verification-needed-noble |
|
| 2024-08-12 14:20:12 |
Nick Rosbrook |
tags |
foundations-todo verification-needed verification-needed-noble |
foundations-todo verification-done verification-done-noble |
|
| 2024-08-22 08:21:18 |
Łukasz Zemczak |
tags |
foundations-todo verification-done verification-done-noble |
foundations-todo verification-needed verification-needed-noble |
|
| 2024-08-22 13:34:38 |
Nick Rosbrook |
tags |
foundations-todo verification-needed verification-needed-noble |
foundations-todo verification-done verification-done-noble |
|
