| 2021-06-03 18:33:50 |
Steve Langasek |
bug |
|
|
added bug |
| 2021-06-03 18:33:58 |
Steve Langasek |
bug task added |
|
grub2-signed (Ubuntu) |
|
| 2021-06-03 18:34:10 |
Steve Langasek |
bug task added |
|
shim-signed (Ubuntu) |
|
| 2021-06-03 18:36:17 |
Steve Langasek |
nominated for series |
|
Ubuntu Xenial |
|
| 2021-06-03 18:36:17 |
Steve Langasek |
bug task added |
|
grub2-signed (Ubuntu Xenial) |
|
| 2021-06-03 18:36:17 |
Steve Langasek |
bug task added |
|
shim-signed (Ubuntu Xenial) |
|
| 2021-06-03 18:36:17 |
Steve Langasek |
bug task added |
|
grub2-unsigned (Ubuntu Xenial) |
|
| 2021-06-03 18:36:17 |
Steve Langasek |
nominated for series |
|
Ubuntu Bionic |
|
| 2021-06-03 18:36:17 |
Steve Langasek |
bug task added |
|
grub2-signed (Ubuntu Bionic) |
|
| 2021-06-03 18:36:17 |
Steve Langasek |
bug task added |
|
shim-signed (Ubuntu Bionic) |
|
| 2021-06-03 18:36:17 |
Steve Langasek |
bug task added |
|
grub2-unsigned (Ubuntu Bionic) |
|
| 2021-06-03 18:37:51 |
Steve Langasek |
grub2-signed (Ubuntu): status |
New |
Invalid |
|
| 2021-06-03 18:37:52 |
Steve Langasek |
grub2-unsigned (Ubuntu): status |
New |
Invalid |
|
| 2021-06-03 18:37:54 |
Steve Langasek |
shim-signed (Ubuntu): status |
New |
Invalid |
|
| 2021-06-03 18:57:05 |
Steve Langasek |
description |
[Impact]
Verification of the previous SRU, bug #1928674, exposed that we have a regression on xenial/arm64 cloud images because they boot from the removable media path, which is not updated by the maintainer scripts in those images; and because we have never supported the monolithic signed EFI executable on xenial/arm64, there is an ABI mismatch between the updated contents of /boot/grub and the not-updated contents of \EFI\boot\bootaa64.efi.
The fact that \EFI\boot is not updated on xenial cloud images is ALSO an issue on amd64 - it doesn't lead to a boot failure there because we do support secureboot on xenial/amd64, so the bootloader doesn't depend on loading modules from /boot/grub; however, \EFI\boot not being uploaded means that the systems still do not benefit from the updated grub, AND are subject to boot failures in the future due to the fact that the old shim has been revoked by Microsoft and these revocations may propagate to the cloud instance's revocation database in nvram, one way or another.
[Test Case]
- Boot an arm64 Ubuntu image in AWS
- Enable -proposed
- Upgrade the grub-efi-amd64 package
- Reboot
- Verify that the system comes up
- Boot an amd64 Ubuntu image in AWS
- rm /boot/efi/EFI/BOOT/BOOTX64.EFI /boot/efi/EFI/BOOT/grubx64.efi
- touch /boot/efi/EFI/BOOT/BOOTX64.EFI /boot/efi/EFI/BOOT/grubx64.efi
- Enabled -proposed
- Upgrade the grub-efi-amd64-signed package
- Reboot
- Verify that the system comes up
- rm /boot/efi/EFI/BOOT/BOOTX64.EFI /boot/efi/EFI/BOOT/grubx64.efi
- touch /boot/efi/EFI/BOOT/BOOTX64.EFI /boot/efi/EFI/BOOT/grubx64.efi
- Upgrade the shim-signed package
- Reboot
- Verify that the system comes up
[Where problems could occur]
Because there were no provisions in the cloud images at the time they were built for updates to \EFI\boot, the only practical way to fix this for existing images (which is where the upgrade bug is an issue) is by unconditionally installing to the removable media path on all systems as part of the upgrade. This means that non-cloud systems, which do not normally boot Ubuntu via \EFI\boot, will have the contents of \EFI\boot replaced when this was not previously the case (and contrary to the debconf setting). In newer Ubuntu releases, we install to \EFI\boot unconditionally; but this is a behavior change in a stable series. If a user has something other than Ubuntu grub+shim installed to \EFI\boot, this may be an unexpected behavior change from an SRU. |
[Impact]
Verification of the previous SRU, bug #1928674, exposed that we have a regression on xenial/arm64 cloud images because they boot from the removable media path, which is not updated by the maintainer scripts in those images; and because we have never supported the monolithic signed EFI executable on xenial/arm64, there is an ABI mismatch between the updated contents of /boot/grub and the not-updated contents of \EFI\boot\bootaa64.efi.
The fact that \EFI\boot is not updated on xenial cloud images is ALSO an issue on amd64 - it doesn't lead to a boot failure there because we do support secureboot on xenial/amd64, so the bootloader doesn't depend on loading modules from /boot/grub; however, \EFI\boot not being uploaded means that the systems still do not benefit from the updated grub, AND are subject to boot failures in the future due to the fact that the old shim has been revoked by Microsoft and these revocations may propagate to the cloud instance's revocation database in nvram, one way or another.
[Test Case]
- Boot an arm64 Ubuntu image in AWS
- Enable -proposed
- Upgrade the grub-efi-amd64 package
- Reboot
- Verify that the system comes up
- Boot an amd64 Ubuntu image in AWS
- rm /boot/efi/EFI/BOOT/BOOTX64.EFI /boot/efi/EFI/BOOT/grubx64.efi
- touch /boot/efi/EFI/BOOT/BOOTX64.EFI /boot/efi/EFI/BOOT/grubx64.efi
- Enabled -proposed
- Upgrade the grub-efi-amd64-signed package
- Reboot
- Verify that the system comes up
- rm /boot/efi/EFI/BOOT/BOOTX64.EFI /boot/efi/EFI/BOOT/grubx64.efi
- touch /boot/efi/EFI/BOOT/BOOTX64.EFI /boot/efi/EFI/BOOT/grubx64.efi
- Upgrade the shim-signed package
- Reboot
- Verify that the system comes up
- Boot an amd64 Ubuntu image in GCE
- rm /boot/efi/EFI/BOOT/BOOTX64.EFI /boot/efi/EFI/BOOT/grubx64.efi
- touch /boot/efi/EFI/BOOT/BOOTX64.EFI /boot/efi/EFI/BOOT/grubx64.efi
- Enabled -proposed
- Upgrade the grub-efi-amd64-signed package
- Reboot
- Verify that the system comes up
- rm /boot/efi/EFI/BOOT/BOOTX64.EFI /boot/efi/EFI/BOOT/grubx64.efi
- touch /boot/efi/EFI/BOOT/BOOTX64.EFI /boot/efi/EFI/BOOT/grubx64.efi
- Upgrade the shim-signed package
- Reboot
- Verify that the system comes up
[Where problems could occur]
Because there were no provisions in the cloud images at the time they were built for updates to \EFI\boot, the only practical way to fix this for existing images (which is where the upgrade bug is an issue) is by unconditionally installing to the removable media path on all systems as part of the upgrade. This means that non-cloud systems, which do not normally boot Ubuntu via \EFI\boot, will have the contents of \EFI\boot replaced when this was not previously the case (and contrary to the debconf setting). In newer Ubuntu releases, we install to \EFI\boot unconditionally; but this is a behavior change in a stable series. If a user has something other than Ubuntu grub+shim installed to \EFI\boot, this may be an unexpected behavior change from an SRU. |
|
| 2021-06-03 18:57:13 |
Steve Langasek |
grub2-signed (Ubuntu Xenial): assignee |
|
Steve Langasek (vorlon) |
|
| 2021-06-03 19:48:46 |
Steve Langasek |
description |
[Impact]
Verification of the previous SRU, bug #1928674, exposed that we have a regression on xenial/arm64 cloud images because they boot from the removable media path, which is not updated by the maintainer scripts in those images; and because we have never supported the monolithic signed EFI executable on xenial/arm64, there is an ABI mismatch between the updated contents of /boot/grub and the not-updated contents of \EFI\boot\bootaa64.efi.
The fact that \EFI\boot is not updated on xenial cloud images is ALSO an issue on amd64 - it doesn't lead to a boot failure there because we do support secureboot on xenial/amd64, so the bootloader doesn't depend on loading modules from /boot/grub; however, \EFI\boot not being uploaded means that the systems still do not benefit from the updated grub, AND are subject to boot failures in the future due to the fact that the old shim has been revoked by Microsoft and these revocations may propagate to the cloud instance's revocation database in nvram, one way or another.
[Test Case]
- Boot an arm64 Ubuntu image in AWS
- Enable -proposed
- Upgrade the grub-efi-amd64 package
- Reboot
- Verify that the system comes up
- Boot an amd64 Ubuntu image in AWS
- rm /boot/efi/EFI/BOOT/BOOTX64.EFI /boot/efi/EFI/BOOT/grubx64.efi
- touch /boot/efi/EFI/BOOT/BOOTX64.EFI /boot/efi/EFI/BOOT/grubx64.efi
- Enabled -proposed
- Upgrade the grub-efi-amd64-signed package
- Reboot
- Verify that the system comes up
- rm /boot/efi/EFI/BOOT/BOOTX64.EFI /boot/efi/EFI/BOOT/grubx64.efi
- touch /boot/efi/EFI/BOOT/BOOTX64.EFI /boot/efi/EFI/BOOT/grubx64.efi
- Upgrade the shim-signed package
- Reboot
- Verify that the system comes up
- Boot an amd64 Ubuntu image in GCE
- rm /boot/efi/EFI/BOOT/BOOTX64.EFI /boot/efi/EFI/BOOT/grubx64.efi
- touch /boot/efi/EFI/BOOT/BOOTX64.EFI /boot/efi/EFI/BOOT/grubx64.efi
- Enabled -proposed
- Upgrade the grub-efi-amd64-signed package
- Reboot
- Verify that the system comes up
- rm /boot/efi/EFI/BOOT/BOOTX64.EFI /boot/efi/EFI/BOOT/grubx64.efi
- touch /boot/efi/EFI/BOOT/BOOTX64.EFI /boot/efi/EFI/BOOT/grubx64.efi
- Upgrade the shim-signed package
- Reboot
- Verify that the system comes up
[Where problems could occur]
Because there were no provisions in the cloud images at the time they were built for updates to \EFI\boot, the only practical way to fix this for existing images (which is where the upgrade bug is an issue) is by unconditionally installing to the removable media path on all systems as part of the upgrade. This means that non-cloud systems, which do not normally boot Ubuntu via \EFI\boot, will have the contents of \EFI\boot replaced when this was not previously the case (and contrary to the debconf setting). In newer Ubuntu releases, we install to \EFI\boot unconditionally; but this is a behavior change in a stable series. If a user has something other than Ubuntu grub+shim installed to \EFI\boot, this may be an unexpected behavior change from an SRU. |
[Impact]
Verification of the previous SRU, bug #1928674, exposed that we have a regression on xenial/arm64 cloud images because they boot from the removable media path, which is not updated by the maintainer scripts in those images; and because we have never supported the monolithic signed EFI executable on xenial/arm64, there is an ABI mismatch between the updated contents of /boot/grub and the not-updated contents of \EFI\boot\bootaa64.efi.
The fact that \EFI\boot is not updated on xenial cloud images is ALSO an issue on amd64 - it doesn't lead to a boot failure there because we do support secureboot on xenial/amd64, so the bootloader doesn't depend on loading modules from /boot/grub; however, \EFI\boot not being uploaded means that the systems still do not benefit from the updated grub, AND are subject to boot failures in the future due to the fact that the old shim has been revoked by Microsoft and these revocations may propagate to the cloud instance's revocation database in nvram, one way or another.
[Test Case]
- Boot an arm64 Ubuntu image in AWS
- Enable -proposed
- Upgrade the grub-efi-amd64 package
- Reboot
- Verify that the system comes up
- Boot an amd64 Ubuntu image in GCE
- rm /boot/efi/EFI/BOOT/BOOTX64.EFI /boot/efi/EFI/BOOT/grubx64.efi
- touch /boot/efi/EFI/BOOT/BOOTX64.EFI /boot/efi/EFI/BOOT/grubx64.efi
- Enabled -proposed
- Upgrade the grub-efi-amd64-signed package
- Reboot
- Verify that the system comes up
- rm /boot/efi/EFI/BOOT/BOOTX64.EFI /boot/efi/EFI/BOOT/grubx64.efi
- touch /boot/efi/EFI/BOOT/BOOTX64.EFI /boot/efi/EFI/BOOT/grubx64.efi
- Upgrade the shim-signed package
- Reboot
- Verify that the system comes up
[Where problems could occur]
Because there were no provisions in the cloud images at the time they were built for updates to \EFI\boot, the only practical way to fix this for existing images (which is where the upgrade bug is an issue) is by unconditionally installing to the removable media path on all systems as part of the upgrade. This means that non-cloud systems, which do not normally boot Ubuntu via \EFI\boot, will have the contents of \EFI\boot replaced when this was not previously the case (and contrary to the debconf setting). In newer Ubuntu releases, we install to \EFI\boot unconditionally; but this is a behavior change in a stable series. If a user has something other than Ubuntu grub+shim installed to \EFI\boot, this may be an unexpected behavior change from an SRU. |
|
| 2021-06-03 21:05:15 |
Steve Langasek |
description |
[Impact]
Verification of the previous SRU, bug #1928674, exposed that we have a regression on xenial/arm64 cloud images because they boot from the removable media path, which is not updated by the maintainer scripts in those images; and because we have never supported the monolithic signed EFI executable on xenial/arm64, there is an ABI mismatch between the updated contents of /boot/grub and the not-updated contents of \EFI\boot\bootaa64.efi.
The fact that \EFI\boot is not updated on xenial cloud images is ALSO an issue on amd64 - it doesn't lead to a boot failure there because we do support secureboot on xenial/amd64, so the bootloader doesn't depend on loading modules from /boot/grub; however, \EFI\boot not being uploaded means that the systems still do not benefit from the updated grub, AND are subject to boot failures in the future due to the fact that the old shim has been revoked by Microsoft and these revocations may propagate to the cloud instance's revocation database in nvram, one way or another.
[Test Case]
- Boot an arm64 Ubuntu image in AWS
- Enable -proposed
- Upgrade the grub-efi-amd64 package
- Reboot
- Verify that the system comes up
- Boot an amd64 Ubuntu image in GCE
- rm /boot/efi/EFI/BOOT/BOOTX64.EFI /boot/efi/EFI/BOOT/grubx64.efi
- touch /boot/efi/EFI/BOOT/BOOTX64.EFI /boot/efi/EFI/BOOT/grubx64.efi
- Enabled -proposed
- Upgrade the grub-efi-amd64-signed package
- Reboot
- Verify that the system comes up
- rm /boot/efi/EFI/BOOT/BOOTX64.EFI /boot/efi/EFI/BOOT/grubx64.efi
- touch /boot/efi/EFI/BOOT/BOOTX64.EFI /boot/efi/EFI/BOOT/grubx64.efi
- Upgrade the shim-signed package
- Reboot
- Verify that the system comes up
[Where problems could occur]
Because there were no provisions in the cloud images at the time they were built for updates to \EFI\boot, the only practical way to fix this for existing images (which is where the upgrade bug is an issue) is by unconditionally installing to the removable media path on all systems as part of the upgrade. This means that non-cloud systems, which do not normally boot Ubuntu via \EFI\boot, will have the contents of \EFI\boot replaced when this was not previously the case (and contrary to the debconf setting). In newer Ubuntu releases, we install to \EFI\boot unconditionally; but this is a behavior change in a stable series. If a user has something other than Ubuntu grub+shim installed to \EFI\boot, this may be an unexpected behavior change from an SRU. |
[Impact]
Verification of the previous SRU, bug #1928674, exposed that we have a regression on xenial/arm64 cloud images because they boot from the removable media path, which is not updated by the maintainer scripts in those images; and because we have never supported the monolithic signed EFI executable on xenial/arm64, there is an ABI mismatch between the updated contents of /boot/grub and the not-updated contents of \EFI\boot\bootaa64.efi.
The fact that \EFI\boot is not updated on xenial cloud images is ALSO an issue on amd64 - it doesn't lead to a boot failure there because we do support secureboot on xenial/amd64, so the bootloader doesn't depend on loading modules from /boot/grub; however, \EFI\boot not being uploaded means that the systems still do not benefit from the updated grub, AND are subject to boot failures in the future due to the fact that the old shim has been revoked by Microsoft and these revocations may propagate to the cloud instance's revocation database in nvram, one way or another.
[Test Case]
- Boot an arm64 Ubuntu image in AWS
- Enable -proposed
- Upgrade the grub-efi-amd64 package
- Reboot
- Verify that the system comes up
- Boot an amd64 Ubuntu image in GCE
- rm /boot/efi/EFI/BOOT/BOOTX64.EFI /boot/efi/EFI/BOOT/grubx64.efi
- touch /boot/efi/EFI/BOOT/BOOTX64.EFI /boot/efi/EFI/BOOT/grubx64.efi
- Enabled -proposed
- Upgrade the grub-efi-amd64-signed package
- Reboot
- Verify that the system comes up
- rm /boot/efi/EFI/BOOT/BOOTX64.EFI /boot/efi/EFI/BOOT/grubx64.efi
- touch /boot/efi/EFI/BOOT/BOOTX64.EFI /boot/efi/EFI/BOOT/grubx64.efi
- Upgrade the shim-signed package
- Reboot
- Verify that the system comes up
[Where problems could occur]
Because there were no provisions in the cloud images at the time they were built for updates to \EFI\boot, the only practical way to fix this for existing images (which is where the upgrade bug is an issue) is by unconditionally installing to the removable media path on all systems as part of the upgrade. This means that non-cloud systems, which do not normally boot Ubuntu via \EFI\boot, will have the contents of \EFI\boot replaced when this was not previously the case (and contrary to the debconf setting). In newer Ubuntu releases, we install to \EFI\boot unconditionally; but this is a behavior change in a stable series. If a user has something other than Ubuntu grub+shim installed to \EFI\boot, this may be an unexpected behavior change from an SRU.
The risk of this causing a problem for users is mitigated on bionic by the fact that all the most recent install media for Ubuntu 18.04 also install shim+grub to the removable path, so this is already the default behavior. |
|
| 2021-06-03 22:08:27 |
Steve Langasek |
grub2-signed (Ubuntu Xenial): status |
New |
In Progress |
|
| 2021-06-03 22:08:30 |
Steve Langasek |
grub2-signed (Ubuntu Bionic): status |
New |
In Progress |
|
| 2021-06-03 22:08:32 |
Steve Langasek |
grub2-unsigned (Ubuntu Xenial): status |
New |
In Progress |
|
| 2021-06-03 22:08:34 |
Steve Langasek |
grub2-unsigned (Ubuntu Bionic): status |
New |
In Progress |
|
| 2021-06-03 22:39:05 |
Steve Langasek |
shim-signed (Ubuntu Xenial): assignee |
|
Steve Langasek (vorlon) |
|
| 2021-06-03 22:44:11 |
Steve Langasek |
shim-signed (Ubuntu Bionic): status |
New |
Invalid |
|
| 2021-06-03 22:48:29 |
Steve Langasek |
tags |
|
regression-update |
|
| 2021-06-04 07:40:47 |
Timo Aaltonen |
grub2-signed (Ubuntu Xenial): status |
In Progress |
Fix Committed |
|
| 2021-06-04 07:40:50 |
Timo Aaltonen |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2021-06-04 07:40:53 |
Timo Aaltonen |
bug |
|
|
added subscriber SRU Verification |
| 2021-06-04 07:40:57 |
Timo Aaltonen |
tags |
regression-update |
regression-update verification-needed verification-needed-xenial |
|
| 2021-06-04 07:43:03 |
Timo Aaltonen |
grub2-signed (Ubuntu Bionic): status |
In Progress |
Fix Committed |
|
| 2021-06-04 07:43:09 |
Timo Aaltonen |
tags |
regression-update verification-needed verification-needed-xenial |
regression-update verification-needed verification-needed-bionic verification-needed-xenial |
|
| 2021-06-04 07:44:27 |
Timo Aaltonen |
grub2-unsigned (Ubuntu Bionic): status |
In Progress |
Fix Committed |
|
| 2021-06-04 16:06:31 |
Steve Langasek |
grub2-unsigned (Ubuntu Xenial): status |
In Progress |
Fix Committed |
|
| 2021-06-04 19:54:54 |
Joshua Powers |
bug |
|
|
added subscriber Joshua Powers |
| 2021-06-07 19:58:45 |
Joshua Powers |
tags |
regression-update verification-needed verification-needed-bionic verification-needed-xenial |
regression-update verification-failed-xenial verification-needed verification-needed-bionic |
|
| 2021-06-07 22:29:31 |
Brian Murray |
tags |
regression-update verification-failed-xenial verification-needed verification-needed-bionic |
regression-update verification-needed verification-needed-bionic verification-needed-xenial |
|
| 2021-06-10 16:06:18 |
Joshua Powers |
tags |
regression-update verification-needed verification-needed-bionic verification-needed-xenial |
regression-update verification-done verification-done-bionic verification-done-xenial |
|
| 2021-06-13 06:30:31 |
Mathew Hodson |
bug |
|
|
added subscriber Mathew Hodson |
| 2021-06-17 17:23:35 |
Launchpad Janitor |
grub2-unsigned (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2021-06-17 17:23:43 |
Launchpad Janitor |
grub2-signed (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2021-06-17 17:23:49 |
Brian Murray |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2021-06-17 17:26:48 |
Launchpad Janitor |
grub2-unsigned (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2021-06-17 17:26:54 |
Launchpad Janitor |
grub2-signed (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2021-06-18 19:20:39 |
Mathew Hodson |
grub2-signed (Ubuntu): status |
Invalid |
Fix Released |
|
| 2021-06-18 19:20:42 |
Mathew Hodson |
grub2-unsigned (Ubuntu): status |
Invalid |
Fix Released |
|
| 2021-06-22 21:51:28 |
Steve Langasek |
shim-signed (Ubuntu Xenial): status |
New |
Fix Committed |
|
| 2021-06-22 21:51:32 |
Steve Langasek |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2021-06-22 21:51:38 |
Steve Langasek |
tags |
regression-update verification-done verification-done-bionic verification-done-xenial |
regression-update verification-done-bionic verification-needed verification-needed-xenial |
|
| 2021-06-24 17:46:03 |
Joshua Powers |
tags |
regression-update verification-done-bionic verification-needed verification-needed-xenial |
regression-update verification-done verification-done-bionic verification-done-xenial |
|
| 2021-07-19 12:36:15 |
Łukasz Zemczak |
tags |
regression-update verification-done verification-done-bionic verification-done-xenial |
regression-update verification-done-bionic verification-needed verification-needed-xenial |
|
| 2021-07-19 15:46:39 |
Joshua Powers |
tags |
regression-update verification-done-bionic verification-needed verification-needed-xenial |
regression-update verification-done verification-done-bionic verification-done-xenial |
|
| 2021-08-16 10:30:18 |
Launchpad Janitor |
shim-signed (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2022-08-26 21:27:35 |
Steve Langasek |
grub2-unsigned (Ubuntu Jammy): status |
New |
Fix Committed |
|
| 2022-08-26 21:27:40 |
Steve Langasek |
tags |
regression-update verification-done verification-done-bionic verification-done-xenial |
regression-update verification-done-bionic verification-done-xenial verification-needed verification-needed-jammy |
|
| 2022-08-27 21:00:42 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~mfo/grub/+git/grub/+merge/429026 |
|
| 2022-08-27 21:31:14 |
Mauricio Faria de Oliveira |
merge proposal unlinked |
https://code.launchpad.net/~mfo/grub/+git/grub/+merge/429026 |
|
|
| 2022-09-22 16:56:43 |
Launchpad Janitor |
grub2-unsigned (Ubuntu Jammy): status |
Fix Committed |
Fix Released |
|
| 2022-09-22 16:56:43 |
Launchpad Janitor |
cve linked |
|
2021-3695 |
|
| 2022-09-22 16:56:43 |
Launchpad Janitor |
cve linked |
|
2021-3696 |
|
| 2022-09-22 16:56:43 |
Launchpad Janitor |
cve linked |
|
2021-3697 |
|
| 2022-09-22 16:56:43 |
Launchpad Janitor |
cve linked |
|
2022-28733 |
|
| 2022-09-22 16:56:43 |
Launchpad Janitor |
cve linked |
|
2022-28734 |
|
| 2022-09-22 16:56:43 |
Launchpad Janitor |
cve linked |
|
2022-28735 |
|
| 2022-09-23 18:19:45 |
Steve Langasek |
grub2-unsigned (Ubuntu Jammy): status |
Fix Released |
Fix Committed |
|
| 2022-10-26 11:33:28 |
Launchpad Janitor |
grub2-unsigned (Ubuntu Jammy): status |
Fix Committed |
Fix Released |
|
| 2024-02-12 14:23:41 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~mkukri/grub/+git/grub/+merge/459698 |
|
| 2024-02-12 14:24:37 |
Launchpad Janitor |
merge proposal unlinked |
https://code.launchpad.net/~mkukri/grub/+git/grub/+merge/459698 |
|
|
