fix grub-install to not write modules to /boot before we know we have a valid disk target
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| grub2 (Ubuntu) |
Fix Released
|
High
|
Unassigned | ||
| Noble |
Fix Released
|
High
|
Unassigned | ||
Bug Description
grub2 2.04-1ubuntu26.2 in 2020 introduced a workaround in focal for the fact that grub2 would write updated modules to /boot/grub, and only afterwards check that it had a valid disk target for installation of the first stage bootloader, with the result that if the debconf config for grub was outdated and points at a device that no longer exists, and there is ABI skew between the 1st/2nd stage bootloader and the grub modules from the new package, the system becomes unbootable because it is unable to load modules from the /boot filesystem, and rollback is not possible (LP: #1889556).
This was supposed to be a workaround, but the work was never done to fix grub-install behavior to avoid this detectable and avoidable failure.
We need grub-install to validate the target disk, and if it is unavailable, abort BEFORE updating /boot/grub with incompatible contents.
Once this is done, the postinst hack that skips grub-install for grub-pc should be dropped.
| tags: | added: foundations-todo |
| Changed in grub2 (Ubuntu): | |
| importance: | Undecided → High |
| Changed in grub2 (Ubuntu Noble): | |
| milestone: | none → ubuntu-24.04-beta |
| Julian Andres Klode (juliank) wrote | #1 |
| Mate Kukri (mkukri) wrote | #2 |
| Changed in grub2 (Ubuntu Noble): | |
| status: | New → Fix Committed |
| Launchpad Janitor (janitor) wrote | #3 |
| Changed in grub2 (Ubuntu Noble): | |
| status: | Fix Committed → Fix Released |
I think we need to have rollback either way, if we have a valid target disk but then fail to write the sectors or we fail halfway building core.mod or something we'd want to try to restore some backup of what we had before.