| 2018-06-27 06:57:07 |
Łukasz Zemczak |
bug |
|
|
added bug |
| 2018-06-27 06:57:18 |
Łukasz Zemczak |
nominated for series |
|
Ubuntu Bionic |
|
| 2018-06-27 06:57:18 |
Łukasz Zemczak |
bug task added |
|
grub2 (Ubuntu Bionic) |
|
| 2018-06-27 06:57:23 |
Łukasz Zemczak |
grub2 (Ubuntu Bionic): status |
New |
Confirmed |
|
| 2018-06-27 06:57:26 |
Łukasz Zemczak |
grub2 (Ubuntu Bionic): assignee |
|
Łukasz Zemczak (sil2100) |
|
| 2018-06-27 06:57:36 |
Łukasz Zemczak |
bug task added |
|
grub2-signed (Ubuntu) |
|
| 2018-06-27 06:57:46 |
Łukasz Zemczak |
bug task added |
|
shim-signed (Ubuntu) |
|
| 2018-06-27 06:57:56 |
Łukasz Zemczak |
bug task added |
|
grub-installer (Ubuntu) |
|
| 2018-06-27 09:00:57 |
Łukasz Zemczak |
description |
There are multiple use cases which require both BIOS and UEFI bootloaders installed on a target image and to keep them both updated.
- cloud images on clouds that support both BIOS and UEFI boot in alternate instance types
- PC installs that should remain bootable in the face of firmware upgrades or reconfigurations
This currently doesn't work because 'grub-install' selects its install target based on which of grub-pc or grub-efi-amd64 is installed.
We should support a package upgrade workflow that supports updating both bootloaders on disk wherever possible, including use of --no-nvram automatically when necessary, and does not fail awkwardly if e.g. the system is booted under BIOS and there is no EFI System Partition present.
The problem is, if the system is booted in BIOS mode and you call grub-install --target=x86_64-efi, the install will fail because it can't write to EFI nvram variables.
There is a --no-nvram flag, but it's incorrect for us to pass this unconditionally, because it's the wrong thing to do when we are booted in UEFI mode.
So we need some smarts in grub-install for an additional mode that only skips nvram if there is no nvram available. |
[Impact]
There are multiple use cases which require both BIOS and UEFI bootloaders installed on a target image and to keep them both updated.
- cloud images on clouds that support both BIOS and UEFI boot in alternate instance types
- PC installs that should remain bootable in the face of firmware upgrades or reconfigurations
This currently doesn't work because 'grub-install' selects its install target based on which of grub-pc or grub-efi-amd64 is installed.
In cosmic we have introduced a --auto-nvram grub-install option that automatically determines if we're running with NVRAM access or not and if yes, updates the NVRAM contents. This allows such dual BIOS-UEFI bootloader setups to work. Same changes are required to be backported to bionic for our cloud images.
[Test Case]
Basic grub2 grub-install test:
* Boot up a bionic system in UEFI mode.
* Upgrade grub2-common to the version in -proposed.
* Run `grub-install --target=x86_64-efi --auto-nvram` and make sure it succeeds.
* Boot up a bionic system in legacy BIOS mode.
* Upgrade grub2-common to the version in -proposed.
* Run `grub-install --target=x86_64-efi --auto-nvram` and make sure it succeeds (actually not doing anything).
Install test for UEFI (repeat for both server-live, server and desktop):
* Download the latest bionic -proposed-enabled image.
* Make sure the image includes the -proposed version of grub2, grub2-signed, shim-signed and grub-installer (and/or ubiquity).
* Install the system normally on an EFI system.
* Reboot and make sure the system is bootable.
Install test for legacy BIOS (repeat for both server-live, server and desktop):
* Download the latest bionic -proposed-enabled image.
* Make sure the image includes the -proposed version of grub2, grub2-signed, shim-signed and grub-installer (and/or ubiquity).
* Install the system normally on a BIOS system.
* Reboot and make sure the system is bootable.
TODO: Add cloud image testing.
[Regression Potential]
The backport introduces a change in the dependency chain for grub which, in some cases, can lead to systems loosing their ability to boot. Basically the symptoms to look for is the inability of booting the installed system on EFI or BIOS. A lot of testing and dogfooding will be required to make sure no installation-case has been broken by this. |
|
| 2018-06-27 09:01:39 |
Łukasz Zemczak |
bug task added |
|
ubiquity (Ubuntu) |
|
| 2018-06-27 09:33:04 |
Łukasz Zemczak |
merge proposal linked |
|
https://code.launchpad.net/~ubuntu-core-dev/shim/+git/shim-signed/+merge/348584 |
|
| 2018-06-27 12:37:22 |
Francis Ginther |
tags |
|
id-5a70e785e0d5f12fa35368a0 |
|
| 2018-06-28 22:14:03 |
Brian Murray |
grub-installer (Ubuntu): status |
New |
Fix Released |
|
| 2018-06-28 22:15:38 |
Brian Murray |
grub-installer (Ubuntu Bionic): status |
New |
Fix Committed |
|
| 2018-06-28 22:15:41 |
Brian Murray |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2018-06-28 22:15:42 |
Brian Murray |
bug |
|
|
added subscriber SRU Verification |
| 2018-06-28 22:15:47 |
Brian Murray |
tags |
id-5a70e785e0d5f12fa35368a0 |
id-5a70e785e0d5f12fa35368a0 verification-needed verification-needed-bionic |
|
| 2018-06-28 22:18:20 |
Brian Murray |
shim-signed (Ubuntu): status |
New |
Fix Released |
|
| 2018-06-28 22:21:21 |
Brian Murray |
shim-signed (Ubuntu Bionic): status |
New |
Fix Committed |
|
| 2018-06-28 22:29:23 |
Brian Murray |
grub2-signed (Ubuntu): status |
New |
Fix Released |
|
| 2018-06-28 22:30:05 |
Brian Murray |
grub2-signed (Ubuntu Bionic): status |
New |
Fix Committed |
|
| 2018-06-28 22:31:53 |
Brian Murray |
grub2 (Ubuntu): status |
New |
Fix Released |
|
| 2018-06-28 22:32:49 |
Brian Murray |
grub2 (Ubuntu Bionic): status |
Confirmed |
Fix Committed |
|
| 2018-06-29 10:05:56 |
Łukasz Zemczak |
ubiquity (Ubuntu): status |
New |
Fix Released |
|
| 2018-06-29 14:04:28 |
Łukasz Zemczak |
ubiquity (Ubuntu Bionic): status |
New |
In Progress |
|
| 2018-06-29 14:04:28 |
Łukasz Zemczak |
ubiquity (Ubuntu Bionic): assignee |
|
Łukasz Zemczak (sil2100) |
|
| 2018-06-29 16:55:03 |
Steve Langasek |
ubiquity (Ubuntu Bionic): status |
In Progress |
Fix Committed |
|
| 2018-07-04 16:33:45 |
Łukasz Zemczak |
description |
[Impact]
There are multiple use cases which require both BIOS and UEFI bootloaders installed on a target image and to keep them both updated.
- cloud images on clouds that support both BIOS and UEFI boot in alternate instance types
- PC installs that should remain bootable in the face of firmware upgrades or reconfigurations
This currently doesn't work because 'grub-install' selects its install target based on which of grub-pc or grub-efi-amd64 is installed.
In cosmic we have introduced a --auto-nvram grub-install option that automatically determines if we're running with NVRAM access or not and if yes, updates the NVRAM contents. This allows such dual BIOS-UEFI bootloader setups to work. Same changes are required to be backported to bionic for our cloud images.
[Test Case]
Basic grub2 grub-install test:
* Boot up a bionic system in UEFI mode.
* Upgrade grub2-common to the version in -proposed.
* Run `grub-install --target=x86_64-efi --auto-nvram` and make sure it succeeds.
* Boot up a bionic system in legacy BIOS mode.
* Upgrade grub2-common to the version in -proposed.
* Run `grub-install --target=x86_64-efi --auto-nvram` and make sure it succeeds (actually not doing anything).
Install test for UEFI (repeat for both server-live, server and desktop):
* Download the latest bionic -proposed-enabled image.
* Make sure the image includes the -proposed version of grub2, grub2-signed, shim-signed and grub-installer (and/or ubiquity).
* Install the system normally on an EFI system.
* Reboot and make sure the system is bootable.
Install test for legacy BIOS (repeat for both server-live, server and desktop):
* Download the latest bionic -proposed-enabled image.
* Make sure the image includes the -proposed version of grub2, grub2-signed, shim-signed and grub-installer (and/or ubiquity).
* Install the system normally on a BIOS system.
* Reboot and make sure the system is bootable.
TODO: Add cloud image testing.
[Regression Potential]
The backport introduces a change in the dependency chain for grub which, in some cases, can lead to systems loosing their ability to boot. Basically the symptoms to look for is the inability of booting the installed system on EFI or BIOS. A lot of testing and dogfooding will be required to make sure no installation-case has been broken by this. |
[Impact]
There are multiple use cases which require both BIOS and UEFI bootloaders installed on a target image and to keep them both updated.
- cloud images on clouds that support both BIOS and UEFI boot in alternate instance types
- PC installs that should remain bootable in the face of firmware upgrades or reconfigurations
This currently doesn't work because 'grub-install' selects its install target based on which of grub-pc or grub-efi-amd64 is installed.
In cosmic we have introduced a --auto-nvram grub-install option that automatically determines if we're running with NVRAM access or not and if yes, updates the NVRAM contents. This allows such dual BIOS-UEFI bootloader setups to work. Same changes are required to be backported to bionic for our cloud images.
[Test Case]
Basic grub2 grub-install test:
* Boot up a bionic system in UEFI mode.
* Upgrade grub2-common to the version in -proposed.
* Run `grub-install --target=x86_64-efi --auto-nvram` and make sure it succeeds.
* Prepare a system with an UEFI installed system that can be booted into in legacy BIOS mode.
* Boot up the bionic system in legacy BIOS mode.
* Upgrade grub2-common to the version in -proposed.
* Run `grub-install --target=x86_64-efi --auto-nvram` and make sure it succeeds (actually not doing anything).
Install test for UEFI (repeat for both server-live, server and desktop):
* Download the latest bionic -proposed-enabled image.
* Make sure the image includes the -proposed version of grub2, grub2-signed, shim-signed and grub-installer (and/or ubiquity).
* Install the system normally on an EFI system.
* Reboot and make sure the system is bootable.
Install test for legacy BIOS (repeat for both server-live, server and desktop):
* Download the latest bionic -proposed-enabled image.
* Make sure the image includes the -proposed version of grub2, grub2-signed, shim-signed and grub-installer (and/or ubiquity).
* Install the system normally on a BIOS system.
* Reboot and make sure the system is bootable.
TODO: Add cloud image testing.
[Regression Potential]
The backport introduces a change in the dependency chain for grub which, in some cases, can lead to systems loosing their ability to boot. Basically the symptoms to look for is the inability of booting the installed system on EFI or BIOS. A lot of testing and dogfooding will be required to make sure no installation-case has been broken by this. |
|
| 2018-07-04 16:37:45 |
Łukasz Zemczak |
description |
[Impact]
There are multiple use cases which require both BIOS and UEFI bootloaders installed on a target image and to keep them both updated.
- cloud images on clouds that support both BIOS and UEFI boot in alternate instance types
- PC installs that should remain bootable in the face of firmware upgrades or reconfigurations
This currently doesn't work because 'grub-install' selects its install target based on which of grub-pc or grub-efi-amd64 is installed.
In cosmic we have introduced a --auto-nvram grub-install option that automatically determines if we're running with NVRAM access or not and if yes, updates the NVRAM contents. This allows such dual BIOS-UEFI bootloader setups to work. Same changes are required to be backported to bionic for our cloud images.
[Test Case]
Basic grub2 grub-install test:
* Boot up a bionic system in UEFI mode.
* Upgrade grub2-common to the version in -proposed.
* Run `grub-install --target=x86_64-efi --auto-nvram` and make sure it succeeds.
* Prepare a system with an UEFI installed system that can be booted into in legacy BIOS mode.
* Boot up the bionic system in legacy BIOS mode.
* Upgrade grub2-common to the version in -proposed.
* Run `grub-install --target=x86_64-efi --auto-nvram` and make sure it succeeds (actually not doing anything).
Install test for UEFI (repeat for both server-live, server and desktop):
* Download the latest bionic -proposed-enabled image.
* Make sure the image includes the -proposed version of grub2, grub2-signed, shim-signed and grub-installer (and/or ubiquity).
* Install the system normally on an EFI system.
* Reboot and make sure the system is bootable.
Install test for legacy BIOS (repeat for both server-live, server and desktop):
* Download the latest bionic -proposed-enabled image.
* Make sure the image includes the -proposed version of grub2, grub2-signed, shim-signed and grub-installer (and/or ubiquity).
* Install the system normally on a BIOS system.
* Reboot and make sure the system is bootable.
TODO: Add cloud image testing.
[Regression Potential]
The backport introduces a change in the dependency chain for grub which, in some cases, can lead to systems loosing their ability to boot. Basically the symptoms to look for is the inability of booting the installed system on EFI or BIOS. A lot of testing and dogfooding will be required to make sure no installation-case has been broken by this. |
[Impact]
There are multiple use cases which require both BIOS and UEFI bootloaders installed on a target image and to keep them both updated.
- cloud images on clouds that support both BIOS and UEFI boot in alternate instance types
- PC installs that should remain bootable in the face of firmware upgrades or reconfigurations
This currently doesn't work because 'grub-install' selects its install target based on which of grub-pc or grub-efi-amd64 is installed.
In cosmic we have introduced a --auto-nvram grub-install option that automatically determines if we're running with NVRAM access or not and if yes, updates the NVRAM contents. This allows such dual BIOS-UEFI bootloader setups to work. Same changes are required to be backported to bionic for our cloud images.
[Test Case]
Basic grub2 grub-install test:
* Boot up a bionic system in UEFI mode.
* Upgrade grub2-common to the version in -proposed.
* Run `grub-install --target=x86_64-efi --auto-nvram` and make sure it succeeds.
* Prepare a system with an UEFI installed system that can be booted into in legacy BIOS mode.
* Boot up the UEFI-installed bionic system in legacy BIOS mode.
* Upgrade grub2-common to the version in -proposed.
* Run `grub-install --target=x86_64-efi --auto-nvram` and make sure it succeeds (actually not doing anything).
Install test for UEFI (repeat for both server-live, server and desktop):
* Download the latest bionic -proposed-enabled image.
* Make sure the image includes the -proposed version of grub2, grub2-signed, shim-signed and grub-installer (and/or ubiquity).
* Install the system normally on an EFI system.
* Reboot and make sure the system is bootable.
Install test for legacy BIOS (repeat for both server-live, server and desktop):
* Download the latest bionic -proposed-enabled image.
* Make sure the image includes the -proposed version of grub2, grub2-signed, shim-signed and grub-installer (and/or ubiquity).
* Install the system normally on a BIOS system.
* Reboot and make sure the system is bootable.
TODO: Add cloud image testing.
[Regression Potential]
The backport introduces a change in the dependency chain for grub which, in some cases, can lead to systems loosing their ability to boot. Basically the symptoms to look for is the inability of booting the installed system on EFI or BIOS. A lot of testing and dogfooding will be required to make sure no installation-case has been broken by this. |
|
| 2018-07-06 21:02:28 |
Launchpad Janitor |
grub-installer (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2018-07-06 21:03:29 |
Launchpad Janitor |
ubiquity (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2018-07-09 10:25:30 |
Łukasz Zemczak |
tags |
id-5a70e785e0d5f12fa35368a0 verification-needed verification-needed-bionic |
id-5a70e785e0d5f12fa35368a0 verification-done-bionic |
|
| 2018-07-09 17:07:06 |
Launchpad Janitor |
grub2 (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2018-07-09 17:07:15 |
Steve Langasek |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2018-07-09 17:07:20 |
Launchpad Janitor |
grub2-signed (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2018-07-09 17:07:26 |
Launchpad Janitor |
shim-signed (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2021-02-10 12:14:03 |
Dimitri John Ledkov |
nominated for series |
|
Ubuntu Xenial |
|
| 2021-02-10 12:14:03 |
Dimitri John Ledkov |
bug task added |
|
grub2 (Ubuntu Xenial) |
|
| 2021-02-10 12:14:03 |
Dimitri John Ledkov |
bug task added |
|
grub-installer (Ubuntu Xenial) |
|
| 2021-02-10 12:14:03 |
Dimitri John Ledkov |
bug task added |
|
ubiquity (Ubuntu Xenial) |
|
| 2021-02-10 12:14:03 |
Dimitri John Ledkov |
bug task added |
|
grub2-signed (Ubuntu Xenial) |
|
| 2021-02-10 12:14:03 |
Dimitri John Ledkov |
bug task added |
|
shim-signed (Ubuntu Xenial) |
|
