[Bug 1891680] [NEW] grub-pc needs to detect when debconf points to invalid drive and stop in preinst, before unpacking files, and also treat this as a failure in postinst
Steve Langasek
1891680 at bugs.launchpad.net
Fri Aug 14 16:17:22 UTC 2020
Public bug reported:
Currently on upgrade if the debconf variable for the drive to install
grub-pc to point to a non-existent drive, the grub package will
nevertheless happily carry on and the postinst will exit 0 - as a result
leaving the /boot/grub contents and the MBR in an inconsistent state,
which due to recent ABI changes will leave the system unbootable on
reboot.
Three changes required in order to make grub upgrades more resilient:
- exit non-zero from the postinst when the drive targets are invalid, so that we signal to the user that there is a problem BEFORE they reboot and give them the opportunity to deal with it. This is addressed by https://code.launchpad.net/~xnox/grub/+git/grub/+merge/388383
- include a check for target drive validity in the grub preinst, not just in the postinst, so that we avoid unpacking boot assets onto disk that might be incorrectly used by another package (despite grub-pc being in an unconfigured state) and still render the system unbootable; this will in general break release upgrades for affected users, but a failing postinst would do the same anyway, and failing early should leave the package manager in a more consistent state overall. This is addressed by https://code.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu/+merge/388423
- modify grub-install so that it handles the flaky part of the install - updating the BIOS disks - FIRST, and aborts if this fails; instead of the current behavior, which is that /boot/grub is updated on disk first, then it attempts to install to the BIOS disk, and if this part fails, no rollback of the contents of /boot/grub is possible.
** Affects: grub2 (Ubuntu)
Importance: Critical
Status: New
** Affects: grub2 (Ubuntu Xenial)
Importance: Critical
Status: New
** Affects: grub2 (Ubuntu Bionic)
Importance: Critical
Status: New
** Affects: grub2 (Ubuntu Focal)
Importance: Critical
Status: New
** Affects: grub2 (Ubuntu Groovy)
Importance: Critical
Status: New
** Changed in: grub2 (Ubuntu)
Importance: Undecided => Critical
** Also affects: grub2 (Ubuntu Bionic)
Importance: Undecided
Status: New
** Also affects: grub2 (Ubuntu Xenial)
Importance: Undecided
Status: New
** Also affects: grub2 (Ubuntu Groovy)
Importance: Critical
Status: New
** Also affects: grub2 (Ubuntu Focal)
Importance: Undecided
Status: New
** Changed in: grub2 (Ubuntu Focal)
Importance: Undecided => Critical
** Changed in: grub2 (Ubuntu Bionic)
Importance: Undecided => Critical
** Changed in: grub2 (Ubuntu Xenial)
Importance: Undecided => Critical
** Description changed:
Currently on upgrade if the debconf variable for the drive to install
grub-pc to point to a non-existent drive, the grub package will
nevertheless happily carry on and the postinst will exit 0 - as a result
leaving the /boot/grub contents and the MBR in an inconsistent state,
which due to recent ABI changes will leave the system unbootable on
reboot.
Three changes required in order to make grub upgrades more resilient:
- exit non-zero from the postinst when the drive targets are invalid, so that we signal to the user that there is a problem BEFORE they reboot and give them the opportunity to deal with it. This is addressed by https://code.launchpad.net/~xnox/grub/+git/grub/+merge/388383
- - include a check for target drive validity in the grub preinst, not just in the postinst, so that we avoid unpacking boot assets onto disk that might be incorrectly used by another package (despite grub-pc being in an unconfigured state) and still render the system unbootable; this will in general break release upgrades for affected users, but a failing postinst would do the same anyway, and failing early should leave the package manager in a more consistent state overall.
+ - include a check for target drive validity in the grub preinst, not just in the postinst, so that we avoid unpacking boot assets onto disk that might be incorrectly used by another package (despite grub-pc being in an unconfigured state) and still render the system unbootable; this will in general break release upgrades for affected users, but a failing postinst would do the same anyway, and failing early should leave the package manager in a more consistent state overall. This is addressed by https://code.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu/+merge/388423
- modify grub-install so that it handles the flaky part of the install - updating the BIOS disks - FIRST, and aborts if this fails; instead of the current behavior, which is that /boot/grub is updated on disk first, then it attempts to install to the BIOS disk, and if this part fails, no rollback of the contents of /boot/grub is possible.
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to grub2 in Ubuntu.
https://bugs.launchpad.net/bugs/1891680
Title:
grub-pc needs to detect when debconf points to invalid drive and stop
in preinst, before unpacking files, and also treat this as a failure
in postinst
Status in grub2 package in Ubuntu:
New
Status in grub2 source package in Xenial:
New
Status in grub2 source package in Bionic:
New
Status in grub2 source package in Focal:
New
Status in grub2 source package in Groovy:
New
Bug description:
Currently on upgrade if the debconf variable for the drive to install
grub-pc to point to a non-existent drive, the grub package will
nevertheless happily carry on and the postinst will exit 0 - as a
result leaving the /boot/grub contents and the MBR in an inconsistent
state, which due to recent ABI changes will leave the system
unbootable on reboot.
Three changes required in order to make grub upgrades more resilient:
- exit non-zero from the postinst when the drive targets are invalid, so that we signal to the user that there is a problem BEFORE they reboot and give them the opportunity to deal with it. This is addressed by https://code.launchpad.net/~xnox/grub/+git/grub/+merge/388383
- include a check for target drive validity in the grub preinst, not just in the postinst, so that we avoid unpacking boot assets onto disk that might be incorrectly used by another package (despite grub-pc being in an unconfigured state) and still render the system unbootable; this will in general break release upgrades for affected users, but a failing postinst would do the same anyway, and failing early should leave the package manager in a more consistent state overall. This is addressed by https://code.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu/+merge/388423
- modify grub-install so that it handles the flaky part of the install - updating the BIOS disks - FIRST, and aborts if this fails; instead of the current behavior, which is that /boot/grub is updated on disk first, then it attempts to install to the BIOS disk, and if this part fails, no rollback of the contents of /boot/grub is possible.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1891680/+subscriptions
More information about the foundations-bugs
mailing list