| 2020-08-14 16:17:22 |
Steve Langasek |
bug |
|
|
added bug |
| 2020-08-14 16:19:06 |
Steve Langasek |
bug |
|
|
added subscriber Dimitri John Ledkov |
| 2020-08-14 16:19:09 |
Steve Langasek |
grub2 (Ubuntu): importance |
Undecided |
Critical |
|
| 2020-08-14 16:19:19 |
Steve Langasek |
nominated for series |
|
Ubuntu Bionic |
|
| 2020-08-14 16:19:19 |
Steve Langasek |
bug task added |
|
grub2 (Ubuntu Bionic) |
|
| 2020-08-14 16:19:19 |
Steve Langasek |
nominated for series |
|
Ubuntu Xenial |
|
| 2020-08-14 16:19:19 |
Steve Langasek |
bug task added |
|
grub2 (Ubuntu Xenial) |
|
| 2020-08-14 16:19:19 |
Steve Langasek |
nominated for series |
|
Ubuntu Groovy |
|
| 2020-08-14 16:19:19 |
Steve Langasek |
bug task added |
|
grub2 (Ubuntu Groovy) |
|
| 2020-08-14 16:19:19 |
Steve Langasek |
nominated for series |
|
Ubuntu Focal |
|
| 2020-08-14 16:19:19 |
Steve Langasek |
bug task added |
|
grub2 (Ubuntu Focal) |
|
| 2020-08-14 16:21:15 |
Steve Langasek |
grub2 (Ubuntu Focal): importance |
Undecided |
Critical |
|
| 2020-08-14 16:21:16 |
Steve Langasek |
grub2 (Ubuntu Bionic): importance |
Undecided |
Critical |
|
| 2020-08-14 16:21:18 |
Steve Langasek |
grub2 (Ubuntu Xenial): importance |
Undecided |
Critical |
|
| 2020-08-14 16:23:11 |
Steve Langasek |
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.
- 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. |
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. |
|
| 2020-08-14 21:12:00 |
Brian Murray |
bug |
|
|
added subscriber Brian Murray |
| 2020-08-17 12:15:13 |
Akbarkhon Variskhanov |
bug |
|
|
added subscriber Akbarkhon Variskhanov |
| 2020-08-17 15:43:32 |
mkurz |
bug |
|
|
added subscriber mkurz |
| 2020-08-17 22:25:59 |
Launchpad Janitor |
grub2 (Ubuntu): status |
New |
Confirmed |
|
| 2020-08-17 22:25:59 |
Launchpad Janitor |
grub2 (Ubuntu Xenial): status |
New |
Confirmed |
|
| 2020-08-17 22:25:59 |
Launchpad Janitor |
grub2 (Ubuntu Bionic): status |
New |
Confirmed |
|
| 2020-08-17 22:25:59 |
Launchpad Janitor |
grub2 (Ubuntu Focal): status |
New |
Confirmed |
|
| 2020-08-18 05:32:35 |
Ikuya Awashiro |
bug |
|
|
added subscriber Ikuya Awashiro |
| 2020-08-18 06:56:48 |
Nicolas Briche |
bug |
|
|
added subscriber Nicolas Briche |
| 2020-08-18 10:06:56 |
Markus Rexhepi-Lindberg |
bug |
|
|
added subscriber Markus Lindberg |
| 2020-08-18 15:59:40 |
nE0sIghT |
bug |
|
|
added subscriber nE0sIghT |
| 2020-08-18 16:18:12 |
Dimitri John Ledkov |
grub2 (Ubuntu Groovy): status |
Confirmed |
In Progress |
|
| 2020-08-18 16:18:15 |
Dimitri John Ledkov |
grub2 (Ubuntu Groovy): assignee |
|
Dimitri John Ledkov (xnox) |
|
| 2020-08-18 17:35:39 |
Dimitri John Ledkov |
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. |
[Impact]
* grub-pc currently installs new core to MBR and installs new modules to /boot in an unsafe manner, which may lead to incompatible combination of MBR and modules resulting in failure to boot.
[Test Case]
* Install using old point media, of an old release. I.e. 16.04.(p-1) for testing upgrades to 18.04 sru, in bios mode.
* backup the contents of /boot
* Configure invalid grub-pc/install_devices to a non existing device
* Upgrade to the package from next series-proposed, non-interactively
* Observe the package installation has failed, the grub-pc package is in a broken state.
* Compare the backup of /boot with current /boot, it should have remained the same, and is different to modules in /usr/lib/grub/i386-pc
* Reboot, reboot should be successful
* install /etc/apparmor.d/usr.sbin.grub-install profile
"/usr/sbin/grub-install" {
capability,
mount,
ptrace,
signal,
unix,
file,
deny /dev/vda w,
}
and load it with
sudo apparmor_parser -r usr.sbin.grub-install
* Set grub-pc/install_devices to the correct existing device
* Attempt non-interactive configuration of the grub-pc package
* Observe the package installation has failed, the grub-pc package is in a broken state.
* Compare the backup of /boot with current /boot, it should have remained the same, and is different to modules in /usr/lib/grub/i386-pc
* Remove the apparmor profile /etc/apparmor.d/usr.sbin.grub-install
* Reboot, reboot should be successful
* Set grub-pc/install_devices to the non-existing device
* Try to configure all the packages, interactively (i.e. using $ sudo dpkg --configure -a or by using $ sudo apt install -f) and ensure to select the right drive for grub installation offer
* Observe that now /boot matches /usr/lib/grub/i386-pc contents, and is different from the backup taken at the start.
[Regression Potential]
* discussion of how regressions are most likely to manifest as a result of this change.
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
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. |
|
| 2020-08-18 17:47:21 |
Dimitri John Ledkov |
description |
[Impact]
* grub-pc currently installs new core to MBR and installs new modules to /boot in an unsafe manner, which may lead to incompatible combination of MBR and modules resulting in failure to boot.
[Test Case]
* Install using old point media, of an old release. I.e. 16.04.(p-1) for testing upgrades to 18.04 sru, in bios mode.
* backup the contents of /boot
* Configure invalid grub-pc/install_devices to a non existing device
* Upgrade to the package from next series-proposed, non-interactively
* Observe the package installation has failed, the grub-pc package is in a broken state.
* Compare the backup of /boot with current /boot, it should have remained the same, and is different to modules in /usr/lib/grub/i386-pc
* Reboot, reboot should be successful
* install /etc/apparmor.d/usr.sbin.grub-install profile
"/usr/sbin/grub-install" {
capability,
mount,
ptrace,
signal,
unix,
file,
deny /dev/vda w,
}
and load it with
sudo apparmor_parser -r usr.sbin.grub-install
* Set grub-pc/install_devices to the correct existing device
* Attempt non-interactive configuration of the grub-pc package
* Observe the package installation has failed, the grub-pc package is in a broken state.
* Compare the backup of /boot with current /boot, it should have remained the same, and is different to modules in /usr/lib/grub/i386-pc
* Remove the apparmor profile /etc/apparmor.d/usr.sbin.grub-install
* Reboot, reboot should be successful
* Set grub-pc/install_devices to the non-existing device
* Try to configure all the packages, interactively (i.e. using $ sudo dpkg --configure -a or by using $ sudo apt install -f) and ensure to select the right drive for grub installation offer
* Observe that now /boot matches /usr/lib/grub/i386-pc contents, and is different from the backup taken at the start.
[Regression Potential]
* discussion of how regressions are most likely to manifest as a result of this change.
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
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. |
[Impact]
* grub-pc currently installs new core to MBR and installs new modules to /boot in an unsafe manner, which may lead to incompatible combination of MBR and modules resulting in failure to boot.
[Test Case]
* Install using old point media, of an old release. I.e. 16.04.(p-1) for testing upgrades to 18.04 sru, in bios mode.
* backup the contents of /boot
* install /etc/apparmor.d/usr.sbin.grub-install profile
"/usr/sbin/grub-install" {
capability,
mount,
ptrace,
signal,
unix,
file,
deny /dev/vda w,
}
and load it with
sudo apparmor_parser -r usr.sbin.grub-install
* Upgrade to the package from next series-proposed, non-interactively
* Observe the package installation has failed, the grub-pc package is in a broken state.
* Compare the backup of /boot with current /boot, it should have remained the same, and is different to modules in /usr/lib/grub/i386-pc
* Remove the apparmor profile /etc/apparmor.d/usr.sbin.grub-install
* Reboot, reboot should be successful. If possible observe the version number in the grub menu, it should still be old.
* Configure invalid grub-pc/install_devices to a non existing device (e.g. /dev/sdk)
* Attempt non-interactive configuration of the grub-pc package
* Observe the package fails, and the grub-pc package remains in a broken state.
* Compare the backup of /boot with current /boot, it should have remained the same, and is different to modules in /usr/lib/grub/i386-pc
* Reboot, reboot should be successful. If possible observe the version number in the grub menu, it should still be old.
* Try to configure all the packages, interactively (i.e. using $ sudo dpkg --configure -a or by using $ sudo apt install -f) and ensure to select the right drive for grub installation offer
* Observe that now /boot matches /usr/lib/grub/i386-pc contents, and is different from the backup taken at the start.
* Reboot should be successful, and grub menu should have the new version number finally
[Regression Potential]
* Existing call to grub-install, is now split into two. And when any
devices fail to configure, non-interactively error is reported just
like it was already done with the interactive case.
It means, it will fail configuration of the package, where
previously it would report success. However, it is now safer and
keeps the system bootable, whilst having unconfigured
packages. This mostly affects non-interactive upgrades, as the
interactive ones have always shown critical errors trying to
correct grub-pc installation problems.
The first stage of grub-install only tries to update the MBR,
whilst utilizing tmpdirectory to create the core image. This is a
slight increase in disk space usage, as previously core was created
in-pace in /boot. Then whilst tmpdir is still populated, /boot
modules and core are upgraded.
These changes do not address multi-mbr systems, or cases where
updating modules fails. For example, it is possible that MBR update
is successful, yet writting updated modules fails, in such scenario
MBR is not rolled back to previous one. Or a case where MBR updates
have succeeded, but only on some devices. A choice has been made to
update modules in /boot, if at least one device has a successful
MBR update. No backup, or rollback of MBR is performed if module
updates fail. This is tricky to do, as it is uncertain if current
MBR matches the core.img & boot.img from /boot, or if some other
bootsectors code was in use before. Ideally in the future,
grub-install itself will be able to stage module updates, and
commit/rollback them upon successful MBR update.
[Other Info]
* Original bug report 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. |
|
| 2020-08-18 17:49:21 |
Dimitri John Ledkov |
description |
[Impact]
* grub-pc currently installs new core to MBR and installs new modules to /boot in an unsafe manner, which may lead to incompatible combination of MBR and modules resulting in failure to boot.
[Test Case]
* Install using old point media, of an old release. I.e. 16.04.(p-1) for testing upgrades to 18.04 sru, in bios mode.
* backup the contents of /boot
* install /etc/apparmor.d/usr.sbin.grub-install profile
"/usr/sbin/grub-install" {
capability,
mount,
ptrace,
signal,
unix,
file,
deny /dev/vda w,
}
and load it with
sudo apparmor_parser -r usr.sbin.grub-install
* Upgrade to the package from next series-proposed, non-interactively
* Observe the package installation has failed, the grub-pc package is in a broken state.
* Compare the backup of /boot with current /boot, it should have remained the same, and is different to modules in /usr/lib/grub/i386-pc
* Remove the apparmor profile /etc/apparmor.d/usr.sbin.grub-install
* Reboot, reboot should be successful. If possible observe the version number in the grub menu, it should still be old.
* Configure invalid grub-pc/install_devices to a non existing device (e.g. /dev/sdk)
* Attempt non-interactive configuration of the grub-pc package
* Observe the package fails, and the grub-pc package remains in a broken state.
* Compare the backup of /boot with current /boot, it should have remained the same, and is different to modules in /usr/lib/grub/i386-pc
* Reboot, reboot should be successful. If possible observe the version number in the grub menu, it should still be old.
* Try to configure all the packages, interactively (i.e. using $ sudo dpkg --configure -a or by using $ sudo apt install -f) and ensure to select the right drive for grub installation offer
* Observe that now /boot matches /usr/lib/grub/i386-pc contents, and is different from the backup taken at the start.
* Reboot should be successful, and grub menu should have the new version number finally
[Regression Potential]
* Existing call to grub-install, is now split into two. And when any
devices fail to configure, non-interactively error is reported just
like it was already done with the interactive case.
It means, it will fail configuration of the package, where
previously it would report success. However, it is now safer and
keeps the system bootable, whilst having unconfigured
packages. This mostly affects non-interactive upgrades, as the
interactive ones have always shown critical errors trying to
correct grub-pc installation problems.
The first stage of grub-install only tries to update the MBR,
whilst utilizing tmpdirectory to create the core image. This is a
slight increase in disk space usage, as previously core was created
in-pace in /boot. Then whilst tmpdir is still populated, /boot
modules and core are upgraded.
These changes do not address multi-mbr systems, or cases where
updating modules fails. For example, it is possible that MBR update
is successful, yet writting updated modules fails, in such scenario
MBR is not rolled back to previous one. Or a case where MBR updates
have succeeded, but only on some devices. A choice has been made to
update modules in /boot, if at least one device has a successful
MBR update. No backup, or rollback of MBR is performed if module
updates fail. This is tricky to do, as it is uncertain if current
MBR matches the core.img & boot.img from /boot, or if some other
bootsectors code was in use before. Ideally in the future,
grub-install itself will be able to stage module updates, and
commit/rollback them upon successful MBR update.
[Other Info]
* Original bug report 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. |
[Impact]
* grub-pc currently installs new core to MBR and installs new modules to /boot in an unsafe manner, which may lead to incompatible combination of MBR and modules resulting in failure to boot.
[Test Case]
* Install using old point media, of an old release. I.e. 16.04.(p-1) for testing upgrades to 18.04 sru, in bios mode.
* backup the contents of /boot
* install /etc/apparmor.d/usr.sbin.grub-install profile
"/usr/sbin/grub-install" {
capability,
mount,
ptrace,
signal,
unix,
file,
deny /dev/* w,
}
and load it with
sudo apparmor_parser -r usr.sbin.grub-install
* Upgrade to the package from next series-proposed, non-interactively
* Observe the package installation has failed, the grub-pc package is in a broken state.
* Compare the backup of /boot with current /boot, it should have remained the same, and is different to modules in /usr/lib/grub/i386-pc
* Remove the apparmor profile /etc/apparmor.d/usr.sbin.grub-install
* Reboot, reboot should be successful. If possible observe the version number in the grub menu, it should still be old.
* Configure invalid grub-pc/install_devices to a non existing device (e.g. /dev/sdk)
* Attempt non-interactive configuration of the grub-pc package
* Observe the package fails, and the grub-pc package remains in a broken state.
* Compare the backup of /boot with current /boot, it should have remained the same, and is different to modules in /usr/lib/grub/i386-pc
* Reboot, reboot should be successful. If possible observe the version number in the grub menu, it should still be old.
* Try to configure all the packages, interactively (i.e. using $ sudo dpkg --configure -a or by using $ sudo apt install -f) and ensure to select the right drive for grub installation offer
* Observe that now /boot matches /usr/lib/grub/i386-pc contents, and is different from the backup taken at the start.
* Reboot should be successful, and grub menu should have the new version number finally
[Regression Potential]
* Existing call to grub-install, is now split into two. And when any
devices fail to configure, non-interactively error is reported just
like it was already done with the interactive case.
It means, it will fail configuration of the package, where
previously it would report success. However, it is now safer and
keeps the system bootable, whilst having unconfigured
packages. This mostly affects non-interactive upgrades, as the
interactive ones have always shown critical errors trying to
correct grub-pc installation problems.
The first stage of grub-install only tries to update the MBR,
whilst utilizing tmpdirectory to create the core image. This is a
slight increase in disk space usage, as previously core was created
in-pace in /boot. Then whilst tmpdir is still populated, /boot
modules and core are upgraded.
These changes do not address multi-mbr systems, or cases where
updating modules fails. For example, it is possible that MBR update
is successful, yet writting updated modules fails, in such scenario
MBR is not rolled back to previous one. Or a case where MBR updates
have succeeded, but only on some devices. A choice has been made to
update modules in /boot, if at least one device has a successful
MBR update. No backup, or rollback of MBR is performed if module
updates fail. This is tricky to do, as it is uncertain if current
MBR matches the core.img & boot.img from /boot, or if some other
bootsectors code was in use before. Ideally in the future,
grub-install itself will be able to stage module updates, and
commit/rollback them upon successful MBR update.
[Other Info]
* Original bug report 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. |
|
| 2020-08-18 17:52:24 |
Dimitri John Ledkov |
description |
[Impact]
* grub-pc currently installs new core to MBR and installs new modules to /boot in an unsafe manner, which may lead to incompatible combination of MBR and modules resulting in failure to boot.
[Test Case]
* Install using old point media, of an old release. I.e. 16.04.(p-1) for testing upgrades to 18.04 sru, in bios mode.
* backup the contents of /boot
* install /etc/apparmor.d/usr.sbin.grub-install profile
"/usr/sbin/grub-install" {
capability,
mount,
ptrace,
signal,
unix,
file,
deny /dev/* w,
}
and load it with
sudo apparmor_parser -r usr.sbin.grub-install
* Upgrade to the package from next series-proposed, non-interactively
* Observe the package installation has failed, the grub-pc package is in a broken state.
* Compare the backup of /boot with current /boot, it should have remained the same, and is different to modules in /usr/lib/grub/i386-pc
* Remove the apparmor profile /etc/apparmor.d/usr.sbin.grub-install
* Reboot, reboot should be successful. If possible observe the version number in the grub menu, it should still be old.
* Configure invalid grub-pc/install_devices to a non existing device (e.g. /dev/sdk)
* Attempt non-interactive configuration of the grub-pc package
* Observe the package fails, and the grub-pc package remains in a broken state.
* Compare the backup of /boot with current /boot, it should have remained the same, and is different to modules in /usr/lib/grub/i386-pc
* Reboot, reboot should be successful. If possible observe the version number in the grub menu, it should still be old.
* Try to configure all the packages, interactively (i.e. using $ sudo dpkg --configure -a or by using $ sudo apt install -f) and ensure to select the right drive for grub installation offer
* Observe that now /boot matches /usr/lib/grub/i386-pc contents, and is different from the backup taken at the start.
* Reboot should be successful, and grub menu should have the new version number finally
[Regression Potential]
* Existing call to grub-install, is now split into two. And when any
devices fail to configure, non-interactively error is reported just
like it was already done with the interactive case.
It means, it will fail configuration of the package, where
previously it would report success. However, it is now safer and
keeps the system bootable, whilst having unconfigured
packages. This mostly affects non-interactive upgrades, as the
interactive ones have always shown critical errors trying to
correct grub-pc installation problems.
The first stage of grub-install only tries to update the MBR,
whilst utilizing tmpdirectory to create the core image. This is a
slight increase in disk space usage, as previously core was created
in-pace in /boot. Then whilst tmpdir is still populated, /boot
modules and core are upgraded.
These changes do not address multi-mbr systems, or cases where
updating modules fails. For example, it is possible that MBR update
is successful, yet writting updated modules fails, in such scenario
MBR is not rolled back to previous one. Or a case where MBR updates
have succeeded, but only on some devices. A choice has been made to
update modules in /boot, if at least one device has a successful
MBR update. No backup, or rollback of MBR is performed if module
updates fail. This is tricky to do, as it is uncertain if current
MBR matches the core.img & boot.img from /boot, or if some other
bootsectors code was in use before. Ideally in the future,
grub-install itself will be able to stage module updates, and
commit/rollback them upon successful MBR update.
[Other Info]
* Original bug report 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. |
[Impact]
* grub-pc currently installs new core to MBR and installs new modules to /boot in an unsafe manner, which may lead to incompatible combination of MBR and modules resulting in failure to boot.
[Test Case]
* Install using old point media, of an old release. I.e. 16.04.(p-1) for testing upgrades to 18.04 sru, in bios mode.
* backup the contents of /boot
* install /etc/apparmor.d/usr.sbin.grub-install profile
"/usr/sbin/grub-install" {
capability,
mount,
ptrace,
signal,
unix,
file,
deny /dev/* w,
}
and load it with
sudo apparmor_parser -r usr.sbin.grub-install
* Upgrade to the package from next series-proposed, non-interactively
* Observe the package installation has failed, the grub-pc package is in a broken state.
* Compare the backup of /boot with current /boot, it should have remained the same, and is different to modules in /usr/lib/grub/i386-pc
* Remove the apparmor profile /etc/apparmor.d/usr.sbin.grub-install
* Reboot, reboot should be successful. If possible observe the version number in the grub menu, it should still be old.
* Configure invalid grub-pc/install_devices to a non existing device (e.g. /dev/sdk)
* Attempt non-interactive configuration of the grub-pc package
* Observe the package fails, and the grub-pc package remains in a broken state.
* Compare the backup of /boot with current /boot, it should have remained the same, and is different to modules in /usr/lib/grub/i386-pc
* Reboot, reboot should be successful. If possible observe the version number in the grub menu, it should still be old.
* Try to configure all the packages, interactively (i.e. using $ sudo dpkg --configure -a or by using $ sudo apt install -f) and ensure to select the right drive for grub installation offer
* Observe that now /boot matches /usr/lib/grub/i386-pc contents, and is different from the backup taken at the start.
* Reboot should be successful, and grub menu should have the new version number finally
[Regression Potential]
* Existing call to grub-install, is now split into two. And when any
devices fail to configure, non-interactively error is reported just
like it was already done with the interactive case.
It means, it will fail configuration of the package, where
previously it would report success. However, it is now safer and
keeps the system bootable, whilst having unconfigured
packages. This mostly affects non-interactive upgrades, as the
interactive ones have always shown critical errors trying to
correct grub-pc installation problems.
The first stage of grub-install only tries to update the MBR,
whilst utilizing tmpdirectory to create the core image. This is a
slight increase in disk space usage, as previously core was created
in-pace in /boot. Then whilst tmpdir is still populated, /boot
modules and core are upgraded.
These changes do not address multi-mbr systems, or cases where
updating modules fails. For example, it is possible that MBR update
is successful, yet writting updated modules fails (out of disk space),
in such scenario MBR is not rolled back to previous one. Or a case
where MBR updates have succeeded, but only on some devices.
A choice has been made to update modules in /boot, if at least one
device has a successful MBR update. No backup, or rollback of MBR is
performed if module updates fail. This is tricky to do, as it is
uncertain if current MBR matches the core.img & boot.img from /boot, or
if some other bootsectors code was in use before. Ideally in the
future, grub-install itself will be able to stage module updates, and
commit/rollback them upon successful MBR update.
[Other Info]
* Original bug report 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. |
|
| 2020-08-18 17:58:16 |
Dimitri John Ledkov |
description |
[Impact]
* grub-pc currently installs new core to MBR and installs new modules to /boot in an unsafe manner, which may lead to incompatible combination of MBR and modules resulting in failure to boot.
[Test Case]
* Install using old point media, of an old release. I.e. 16.04.(p-1) for testing upgrades to 18.04 sru, in bios mode.
* backup the contents of /boot
* install /etc/apparmor.d/usr.sbin.grub-install profile
"/usr/sbin/grub-install" {
capability,
mount,
ptrace,
signal,
unix,
file,
deny /dev/* w,
}
and load it with
sudo apparmor_parser -r usr.sbin.grub-install
* Upgrade to the package from next series-proposed, non-interactively
* Observe the package installation has failed, the grub-pc package is in a broken state.
* Compare the backup of /boot with current /boot, it should have remained the same, and is different to modules in /usr/lib/grub/i386-pc
* Remove the apparmor profile /etc/apparmor.d/usr.sbin.grub-install
* Reboot, reboot should be successful. If possible observe the version number in the grub menu, it should still be old.
* Configure invalid grub-pc/install_devices to a non existing device (e.g. /dev/sdk)
* Attempt non-interactive configuration of the grub-pc package
* Observe the package fails, and the grub-pc package remains in a broken state.
* Compare the backup of /boot with current /boot, it should have remained the same, and is different to modules in /usr/lib/grub/i386-pc
* Reboot, reboot should be successful. If possible observe the version number in the grub menu, it should still be old.
* Try to configure all the packages, interactively (i.e. using $ sudo dpkg --configure -a or by using $ sudo apt install -f) and ensure to select the right drive for grub installation offer
* Observe that now /boot matches /usr/lib/grub/i386-pc contents, and is different from the backup taken at the start.
* Reboot should be successful, and grub menu should have the new version number finally
[Regression Potential]
* Existing call to grub-install, is now split into two. And when any
devices fail to configure, non-interactively error is reported just
like it was already done with the interactive case.
It means, it will fail configuration of the package, where
previously it would report success. However, it is now safer and
keeps the system bootable, whilst having unconfigured
packages. This mostly affects non-interactive upgrades, as the
interactive ones have always shown critical errors trying to
correct grub-pc installation problems.
The first stage of grub-install only tries to update the MBR,
whilst utilizing tmpdirectory to create the core image. This is a
slight increase in disk space usage, as previously core was created
in-pace in /boot. Then whilst tmpdir is still populated, /boot
modules and core are upgraded.
These changes do not address multi-mbr systems, or cases where
updating modules fails. For example, it is possible that MBR update
is successful, yet writting updated modules fails (out of disk space),
in such scenario MBR is not rolled back to previous one. Or a case
where MBR updates have succeeded, but only on some devices.
A choice has been made to update modules in /boot, if at least one
device has a successful MBR update. No backup, or rollback of MBR is
performed if module updates fail. This is tricky to do, as it is
uncertain if current MBR matches the core.img & boot.img from /boot, or
if some other bootsectors code was in use before. Ideally in the
future, grub-install itself will be able to stage module updates, and
commit/rollback them upon successful MBR update.
[Other Info]
* Original bug report 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. |
[Impact]
* grub-pc currently installs new core to MBR and installs new modules to /boot in an unsafe manner, which may lead to incompatible combination of MBR and modules resulting in failure to boot.
[Test Case]
* Install using old point media, of an old release. I.e. 16.04.(p-1) for testing upgrades to 18.04 sru, in bios mode.
* backup the contents of /boot
* First we will test a case where target boot device exists, yet writes to it are denied, thus one can update modules, but cannot update the MBR.
* install /etc/apparmor.d/usr.sbin.grub-install profile
"/usr/sbin/grub-install" {
capability,
mount,
ptrace,
signal,
unix,
file,
deny /dev/* w,
}
and load it with
sudo apparmor_parser -r usr.sbin.grub-install
* Upgrade to the package from next series-proposed, non-interactively
* Observe the package installation has failed, the grub-pc package is in a broken state.
* Compare the backup of /boot with current /boot, it should have remained the same, and is different to modules in /usr/lib/grub/i386-pc
* Remove the apparmor profile /etc/apparmor.d/usr.sbin.grub-install
* Reboot, reboot should be successful. If possible observe the version number in the grub menu, it should still be old.
* Now we will test a case where a non-existing device ended up being configured in debconf. For example, due to old buggy cloud-init having been used during first boot, or because the VM got migrated from one hardware configuration to another (i.e. offline switch from SCSI sda, to VIRTIO vda).
* Configure invalid grub-pc/install_devices to a non existing device (e.g. /dev/sdk)
* Attempt non-interactive configuration of the grub-pc package
* Observe the package fails, and the grub-pc package remains in a broken state.
* Compare the backup of /boot with current /boot, it should have remained the same, and is different to modules in /usr/lib/grub/i386-pc
* Reboot, reboot should be successful. If possible observe the version number in the grub menu, it should still be old.
* Try to configure all the packages, interactively (i.e. using $ sudo dpkg --configure -a or by using $ sudo apt install -f) and ensure to select the right drive for grub installation offer
* Observe that now /boot matches /usr/lib/grub/i386-pc contents, and is different from the backup taken at the start.
* Reboot should be successful, and grub menu should have the new version number finally
[Regression Potential]
* Existing call to grub-install, is now split into two. And when any
devices fail to configure, non-interactively error is reported just
like it was already done with the interactive case.
It means, it will fail configuration of the package, where
previously it would report success. However, it is now safer and
keeps the system bootable, whilst having unconfigured
packages. This mostly affects non-interactive upgrades, as the
interactive ones have always shown critical errors trying to
correct grub-pc installation problems.
The first stage of grub-install only tries to update the MBR,
whilst utilizing tmpdirectory to create the core image. This is a
slight increase in disk space usage, as previously core was created
in-pace in /boot. Then whilst tmpdir is still populated, /boot
modules and core are upgraded.
These changes do not address multi-mbr systems, or cases where
updating modules fails. For example, it is possible that MBR update
is successful, yet writting updated modules fails (out of disk space),
in such scenario MBR is not rolled back to previous one. Or a case
where MBR updates have succeeded, but only on some devices.
A choice has been made to update modules in /boot, if at least one
device has a successful MBR update. No backup, or rollback of MBR is
performed if module updates fail. This is tricky to do, as it is
uncertain if current MBR matches the core.img & boot.img from /boot, or
if some other bootsectors code was in use before. Ideally in the
future, grub-install itself will be able to stage module updates, and
commit/rollback them upon successful MBR update.
[Other Info]
* Original bug report 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. |
|
| 2020-08-18 21:42:36 |
Andrei Shevchuk |
bug |
|
|
added subscriber Andrei Shevchuk |
| 2020-08-19 09:05:55 |
thinkpad |
bug |
|
|
added subscriber thinkpad |
| 2020-08-19 16:17:25 |
Oleg "Nightwing" Lomakin |
bug |
|
|
added subscriber Oleg "Nightwing" Lomakin |
| 2020-08-22 17:02:37 |
P. Oscar Boykin |
bug |
|
|
added subscriber P. Oscar Boykin |
| 2020-08-23 01:04:15 |
Toby Petty |
bug |
|
|
added subscriber Toby Petty |
| 2020-08-24 09:42:20 |
Stefan Luik |
bug |
|
|
added subscriber Stefan Luik |
| 2020-08-25 14:25:42 |
Alberto Mardegan |
bug |
|
|
added subscriber Alberto Mardegan |
| 2020-08-25 18:39:22 |
Fizzfadlt |
bug |
|
|
added subscriber Fizzfadlt |
| 2020-08-25 23:02:48 |
Mike |
bug |
|
|
added subscriber Mike |
| 2020-08-26 10:14:29 |
san03 |
bug |
|
|
added subscriber Philipp |
| 2020-08-26 21:47:43 |
Victor Gonzalez |
bug |
|
|
added subscriber Victor Gonzalez |
| 2020-08-27 20:44:55 |
Windmark |
bug |
|
|
added subscriber Windmark |
| 2020-08-27 23:50:35 |
Jim Kleckner |
bug |
|
|
added subscriber Jim Kleckner |
| 2020-08-28 14:24:00 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~xnox/grub/+git/grub/+merge/389968 |
|
| 2020-08-28 15:04:39 |
Tero Gusto |
bug |
|
|
added subscriber Tero Gusto |
| 2020-08-30 22:57:45 |
Patric |
bug |
|
|
added subscriber Patric |
| 2020-08-30 23:39:38 |
Chaos |
bug |
|
|
added subscriber Chaos |
| 2020-09-01 09:30:08 |
Christian Limberg |
bug |
|
|
added subscriber Christian Limberg |
| 2020-09-02 01:28:51 |
Kai Kasurinen |
bug |
|
|
added subscriber Kai Kasurinen |
| 2020-09-02 12:55:35 |
Francis Ginther |
tags |
|
id-5f36bab45785997ba0092e8a |
|
| 2020-09-02 16:10:04 |
Steve Langasek |
grub2 (Ubuntu Groovy): status |
In Progress |
Fix Committed |
|
| 2020-09-02 19:20:54 |
Launchpad Janitor |
grub2 (Ubuntu Groovy): status |
Fix Committed |
Fix Released |
|
| 2020-09-03 07:43:56 |
Jonas O |
bug |
|
|
added subscriber Jonas O |
| 2020-09-04 15:10:25 |
seyfullah ari |
bug |
|
|
added subscriber seyfullah ari |
| 2020-09-06 06:41:07 |
Kyle Miller |
bug |
|
|
added subscriber Kyle Miller |
| 2020-09-06 07:47:05 |
Will |
bug |
|
|
added subscriber Will |
| 2020-09-06 13:58:41 |
MohammadHossein Bagheri |
bug |
|
|
added subscriber MohammadHossein Bagheri |
| 2020-09-07 05:39:05 |
ctorrens |
bug |
|
|
added subscriber Iced |
| 2020-09-07 06:21:03 |
Ulf |
bug |
|
|
added subscriber Ulf |
| 2020-09-07 07:19:54 |
Roemer Claasen |
bug |
|
|
added subscriber Roemer Claasen |
| 2020-09-07 19:59:41 |
Nikolai Kristiansen |
bug |
|
|
added subscriber Nikolai Kristiansen |
| 2020-09-08 10:41:16 |
Dimitri John Ledkov |
grub2 (Ubuntu Focal): status |
Confirmed |
In Progress |
|
| 2020-09-09 01:26:03 |
Peter Martini |
bug |
|
|
added subscriber Peter Martini |
| 2020-09-09 10:18:17 |
Plinio de Paula |
bug |
|
|
added subscriber Plinio de Paula |
| 2020-09-09 11:15:15 |
Maximilian Schleiss |
bug |
|
|
added subscriber Maximilian Schleiss |
| 2020-09-09 16:47:55 |
costinel |
bug |
|
|
added subscriber costinel |
| 2020-09-09 18:41:12 |
Romwriter |
bug |
|
|
added subscriber Romwriter Launchpad |
| 2020-09-09 20:39:20 |
Steve Langasek |
grub2 (Ubuntu Focal): status |
In Progress |
Fix Committed |
|
| 2020-09-09 20:39:25 |
Steve Langasek |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2020-09-09 20:39:27 |
Steve Langasek |
bug |
|
|
added subscriber SRU Verification |
| 2020-09-09 20:39:47 |
Steve Langasek |
tags |
id-5f36bab45785997ba0092e8a |
id-5f36bab45785997ba0092e8a verification-needed verification-needed-focal |
|
| 2020-09-09 21:20:32 |
Emanuel Evans |
bug |
|
|
added subscriber Emanuel Evans |
| 2020-09-10 00:52:26 |
Dave Butcher |
bug |
|
|
added subscriber Dave Butcher |
| 2020-09-10 15:36:47 |
Andrew Cloke |
bug |
|
|
added subscriber Andrew Cloke |
| 2020-09-11 11:43:17 |
Glenn |
bug |
|
|
added subscriber Glenn |
| 2020-09-11 14:14:10 |
Andrew Minter |
bug |
|
|
added subscriber Andrew Minter |
| 2020-09-12 01:52:33 |
Ben Kietzman |
bug |
|
|
added subscriber Ben Kietzman |
| 2020-09-13 12:27:00 |
Alexander Yesipov |
bug |
|
|
added subscriber Alexander Yesipov |
| 2020-09-14 11:19:26 |
Leopoldo |
bug |
|
|
added subscriber Leopoldo |
| 2020-09-15 00:48:51 |
xfool |
bug |
|
|
added subscriber xfool |
| 2020-09-15 10:54:58 |
Dimitri John Ledkov |
tags |
id-5f36bab45785997ba0092e8a verification-needed verification-needed-focal |
id-5f36bab45785997ba0092e8a verification-done verification-done-focal |
|
| 2020-09-15 19:42:47 |
Louis Fall |
grub2 (Ubuntu Focal): status |
Fix Committed |
Fix Released |
|
| 2020-09-15 20:12:56 |
Brian Murray |
grub2 (Ubuntu Focal): status |
Fix Released |
Fix Committed |
|
| 2020-09-16 00:03:36 |
Launchpad Janitor |
grub2 (Ubuntu Focal): status |
Fix Committed |
Fix Released |
|
| 2020-09-16 00:03:43 |
Steve Langasek |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2020-09-16 04:22:28 |
Erick Brunzell |
bug |
|
|
added subscriber Erick Brunzell |
| 2020-09-16 21:59:11 |
Rob |
bug |
|
|
added subscriber Rob |
| 2020-09-17 21:53:04 |
dann frazier |
bug |
|
|
added subscriber dann frazier |
| 2020-09-18 10:41:57 |
Eduard Hasenleithner |
bug |
|
|
added subscriber Eduard Hasenleithner |
| 2020-09-20 06:57:43 |
matt604 |
bug |
|
|
added subscriber matt604 |
| 2020-09-20 08:52:06 |
Lance |
bug |
|
|
added subscriber Lance |
| 2020-09-24 08:47:52 |
Luca Passini |
bug |
|
|
added subscriber Luca Passini |
| 2020-09-24 11:04:54 |
Seb Bonnard |
bug |
|
|
added subscriber Seb Bonnard |
| 2020-09-24 12:42:17 |
Adam Nofsinger |
bug |
|
|
added subscriber Adam Nofsinger |
| 2020-09-24 23:29:57 |
Erik |
bug |
|
|
added subscriber Erik |
| 2020-09-28 10:59:49 |
guillaume ramelet |
bug |
|
|
added subscriber guillaume ramelet |
| 2020-09-29 18:43:11 |
Glenn |
removed subscriber Glenn |
|
|
|
| 2020-09-30 09:54:04 |
BDisp |
bug |
|
|
added subscriber BDisp |
| 2020-09-30 12:02:54 |
T.J. Cravey |
removed subscriber T.J. Cravey |
|
|
|
| 2020-09-30 16:58:40 |
Emanuel Evans |
removed subscriber Emanuel Evans |
|
|
|
| 2020-10-05 01:01:48 |
guillaume ramelet |
removed subscriber guillaume ramelet |
|
|
|
| 2020-10-05 11:42:17 |
Rich Vertigan |
removed subscriber Rich Vertigan |
|
|
|
| 2020-10-08 12:53:00 |
radiovirusgenerator |
bug |
|
|
added subscriber radiovirusgenerator |
| 2020-10-14 15:48:30 |
Matthieu Clemenceau |
tags |
id-5f36bab45785997ba0092e8a verification-done verification-done-focal |
fr-114 id-5f36bab45785997ba0092e8a verification-done verification-done-focal |
|
| 2020-10-27 20:10:00 |
Brian Murray |
grub2 (Ubuntu Bionic): status |
Confirmed |
Fix Committed |
|
| 2020-10-27 20:10:06 |
Brian Murray |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2020-10-27 20:10:40 |
Brian Murray |
tags |
fr-114 id-5f36bab45785997ba0092e8a verification-done verification-done-focal |
fr-114 id-5f36bab45785997ba0092e8a verification-done-focal verification-needed verification-needed-bionic |
|
| 2020-10-28 02:15:34 |
Fizzfadlt |
removed subscriber Fizzfadlt |
|
|
|
| 2020-11-10 10:50:42 |
Dimitri John Ledkov |
tags |
fr-114 id-5f36bab45785997ba0092e8a verification-done-focal verification-needed verification-needed-bionic |
fr-114 id-5f36bab45785997ba0092e8a verification-done verification-done-bionic verification-done-focal |
|
| 2020-11-12 12:27:57 |
Launchpad Janitor |
grub2 (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2020-11-17 13:05:56 |
Leopoldo |
removed subscriber Leopoldo |
|
|
|
