grub-pc reinstallation throws a prompt asking the device it should install on for Noble
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cloud-images |
Fix Released
|
Undecided
|
Utkarsh Gupta | ||
grub2 (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Noble |
New
|
Undecided
|
Unassigned | ||
ubuntu-release-upgrader (Ubuntu) |
Invalid
|
Undecided
|
Mate Kukri | ||
Noble |
In Progress
|
Undecided
|
Unassigned |
Bug 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 ]
* Use debconf-show grub-pc, and look for grub-{pc,
* 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/
* 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:/
Before the commit https:/
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:/
The plausible solution is to develop something to set the grub-pc/
Related branches
- Philip Roche (community): Approve
- Utkarsh Gupta: Approve
- Nick Rosbrook: Approve
- Julian Andres Klode: Pending requested
- Ubuntu Core Development Team: Pending requested
-
Diff: 39 lines (+24/-0)1 file modifiedDistUpgrade/DistUpgradeQuirks.py (+24/-0)
- Mate Kukri: Approve
- Utkarsh Gupta: Approve
-
Diff: 29 lines (+10/-0)2 files modifieddebian/changelog (+7/-0)
live-build/ubuntu-cpc/hooks.d/base/disk-image-uefi.binary (+3/-0)
description: | updated |
Changed in cloud-images: | |
status: | New → Fix Released |
assignee: | nobody → Utkarsh Gupta (utkarsh) |
Changed in ubuntu-release-upgrader (Ubuntu): | |
assignee: | nobody → Mate Kukri (mkukri) |
description: | updated |
description: | updated |
Changed in ubuntu-release-upgrader (Ubuntu): | |
status: | New → Invalid |
Changed in ubuntu-release-upgrader (Ubuntu Noble): | |
status: | New → In Progress |
First we are going to change grub to not hard-error when `grub-pc/ install_ devices` is empty, in order to avoid worse regressions than grub-pc simply being outdated on disk.
Second, since we know the image layout on cloud images, we can use `grub-probe` to determine the install device based on the filesystem containing the `/boot` directory.
We are introducing the `grub-{ efi,pc} /cloud_ style_installat ion` debconf option to determine the install device using `grub-probe` dynamically instead of having to fill the `grub-pc/ install- devices` debconf entry.
This can then be set in cloud images at build time, and reinstallation should just work this way without having to introduce a new service.