[Bug 1783057] [NEW] Allow support of Secure Boot without touching NVRAM

[Daniel Richard G.]

Public bug reported:

This concerns shim 13-0ubuntu2 in Ubuntu 18.04/bionic.

(Note: I am not entirely clear on whether this issue belongs to shim, or
to grub2; please redirect as appropriate.)

I am installing Ubuntu with EFI support with the following two
prerequisites:

  1. No changes are made to NVRAM (the system boots via e.g. "ATA HDD0"
instead of a dedicated boot option);

  2. The EFI removable media path (BOOT/BOOTX64.EFI) is used. (This is
kind of required by #1)

I have confirmed that this arrangement can be booted in Secure Boot mode
if the following two changes are made:

  1. BOOT/fbx64.efi is removed, to eliminate boot-loop behavior (same
issue as in https://launchpad.net/bugs/1750351, only unlocking the boot
order is not an option), and

  2. grubx64.efi and grub.cfg are copied from ubuntu/ into BOOT/ (as
BOOTX64!shim otherwise complains about not being able to find grubx64).

I would like for it to be possible to install Ubuntu in Secure Boot mode
in this manner, as the current approach effectively negates the intent
of the update_nvram=false debconf selection.

** Affects: shim (Ubuntu)
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to shim in Ubuntu.
https://bugs.launchpad.net/bugs/1783057

Title:
  Allow support of Secure Boot without touching NVRAM

Status in shim package in Ubuntu:
  New

Bug description:
  This concerns shim 13-0ubuntu2 in Ubuntu 18.04/bionic.

  (Note: I am not entirely clear on whether this issue belongs to shim,
  or to grub2; please redirect as appropriate.)

  I am installing Ubuntu with EFI support with the following two
  prerequisites:

    1. No changes are made to NVRAM (the system boots via e.g. "ATA
  HDD0" instead of a dedicated boot option);

    2. The EFI removable media path (BOOT/BOOTX64.EFI) is used. (This is
  kind of required by #1)

  I have confirmed that this arrangement can be booted in Secure Boot
  mode if the following two changes are made:

    1. BOOT/fbx64.efi is removed, to eliminate boot-loop behavior (same
  issue as in https://launchpad.net/bugs/1750351, only unlocking the
  boot order is not an option), and

    2. grubx64.efi and grub.cfg are copied from ubuntu/ into BOOT/ (as
  BOOTX64!shim otherwise complains about not being able to find
  grubx64).

  I would like for it to be possible to install Ubuntu in Secure Boot
  mode in this manner, as the current approach effectively negates the
  intent of the update_nvram=false debconf selection.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/shim/+bug/1783057/+subscriptions