[Bug 1915536] Re: one grub

[Dimitri John Ledkov]

** Description changed:

  [Impact]
  
   * Currently one needs grub-$platform-bin and grub-$platform-signed
  packages installed together. As first one provides modules, and the
  later one provides signed .efi images. The two are built from different
  source packages, and there is a delay of manual reviews before matching
  signed grub appears.
  
-  * The proposal is to rename modules in -bin to be shipped in the
+  * The proposal is to rename modules in -bin to be shipped in the
  $platfrom-unsigned directly.
  
-  * And make -signed package ship both modules and signed binaries
+  * And make -signed-bin package ship modules
  
-  * And add dependency from the -bin onto > -signed one, such that grub
- uses whichever modules match the signed images.
+  * And add dependency from the -bin onto > -signed-bin one
  
-  * This allows allows in the future for grub2-signed to pull appropriate
+  * This allows allows in the future for grub2-signed to pull appropriate
  grub modules for a given distro. For example, using 2.04 modules &
  signed images from focal on bionic to gain support for TPM verifies and
  other EFI platform specific developments without affecting userspace
  grub tooling.
  
+ [Caveats]
+ 
+ * If one chooses to remove or not install grub-efi-*-signed package,
+ then modules keep receiving updates, but no SRUs of grub-efi-amd64/grub-
+ efi-arm64 getting published meaning nothing is upgraded that has a
+ maintainer script to trigger grub-install. This is closer inline with
+ grub-pc which also stopped calling grub-install in the release series.
+ But I feel iffy about this.
+ 
+ but i'm not sure if it is ok to add circular dependency from grub-
+ efi-*-bin back onto grub-efi-amd64/grub-efi-amd64/signed/grub-pc.
+ 
+ almost as if the top level packages should simply have a file trigger on
+ modules directory to trigger upgrade logic to execute grub-install.
+ 
+ also feel iffy about the fact that -signed ships efi apps; -signed-bin
+ ships modules; and -signed-dbg ships debug ones. collapsing them all
+ into one will break the multiarch-foreign constraint on the unsigned
+ -bin packages.
+ 
+ I guess question remains if i should add file-triggers in the grub-pc &
+ grub-efi-arm64|amd64-signed packages.
+ 
  [Test Case]
  
   * Upgrade to new grub-efi-amd64-bin and grub-efi-amd64-signed packages
  
-  * Observe that system boots, one can use grub-mkimage / grub-mkrescue
+  * Observe that system boots, one can use grub-mkimage / grub-mkrescue
  without issues.
  
  [Where problems could occur]
  
   * The binaries shipped by -signed packages are innert, they are
  bootloader binaries only. The only compatibility that has to be
  maintained is within the userspace tooling - specifically maintainer
  scripts, and file names and locations.
  
  [Other Info]
  
   * See all the bug reports that grub can't be installed or upgraded when
  people use -proposed.

** Description changed:

  [Impact]
  
   * Currently one needs grub-$platform-bin and grub-$platform-signed
  packages installed together. As first one provides modules, and the
  later one provides signed .efi images. The two are built from different
  source packages, and there is a delay of manual reviews before matching
  signed grub appears.
  
   * The proposal is to rename modules in -bin to be shipped in the
  $platfrom-unsigned directly.
  
   * And make -signed-bin package ship modules
  
   * And add dependency from the -bin onto > -signed-bin one
  
   * This allows allows in the future for grub2-signed to pull appropriate
  grub modules for a given distro. For example, using 2.04 modules &
  signed images from focal on bionic to gain support for TPM verifies and
  other EFI platform specific developments without affecting userspace
  grub tooling.
  
  [Caveats]
  
  * If one chooses to remove or not install grub-efi-*-signed package,
  then modules keep receiving updates, but no SRUs of grub-efi-amd64/grub-
  efi-arm64 getting published meaning nothing is upgraded that has a
  maintainer script to trigger grub-install. This is closer inline with
  grub-pc which also stopped calling grub-install in the release series.
  But I feel iffy about this.
  
  but i'm not sure if it is ok to add circular dependency from grub-
  efi-*-bin back onto grub-efi-amd64/grub-efi-amd64/signed/grub-pc.
  
  almost as if the top level packages should simply have a file trigger on
  modules directory to trigger upgrade logic to execute grub-install.
  
  also feel iffy about the fact that -signed ships efi apps; -signed-bin
  ships modules; and -signed-dbg ships debug ones. collapsing them all
  into one will break the multiarch-foreign constraint on the unsigned
  -bin packages.
  
  I guess question remains if i should add file-triggers in the grub-pc &
  grub-efi-arm64|amd64-signed packages.
  
+ The advantage of file-trigger would be that grub-efi-*-signed packages
+ no longer need to ship any maitaniner scripts, and can be multiarch
+ foreign providing modules & efi apps (and dbg modules separate).
+ 
  [Test Case]
  
   * Upgrade to new grub-efi-amd64-bin and grub-efi-amd64-signed packages
  
   * Observe that system boots, one can use grub-mkimage / grub-mkrescue
  without issues.
  
  [Where problems could occur]
  
   * The binaries shipped by -signed packages are innert, they are
  bootloader binaries only. The only compatibility that has to be
  maintained is within the userspace tooling - specifically maintainer
  scripts, and file names and locations.
  
  [Other Info]
  
   * See all the bug reports that grub can't be installed or upgraded when
  people use -proposed.

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

Title:
  one grub

Status in grub2 package in Ubuntu:
  New
Status in grub2-signed package in Ubuntu:
  New

Bug description:
  [Impact]

   * Currently one needs grub-$platform-bin and grub-$platform-signed
  packages installed together. As first one provides modules, and the
  later one provides signed .efi images. The two are built from
  different source packages, and there is a delay of manual reviews
  before matching signed grub appears.

   * The proposal is to rename modules in -bin to be shipped in the
  $platfrom-unsigned directly.

   * And make -signed-bin package ship modules

   * And add dependency from the -bin onto > -signed-bin one

   * This allows allows in the future for grub2-signed to pull
  appropriate grub modules for a given distro. For example, using 2.04
  modules & signed images from focal on bionic to gain support for TPM
  verifies and other EFI platform specific developments without
  affecting userspace grub tooling.

  [Caveats]

  * If one chooses to remove or not install grub-efi-*-signed package,
  then modules keep receiving updates, but no SRUs of grub-efi-amd64
  /grub-efi-arm64 getting published meaning nothing is upgraded that has
  a maintainer script to trigger grub-install. This is closer inline
  with grub-pc which also stopped calling grub-install in the release
  series. But I feel iffy about this.

  but i'm not sure if it is ok to add circular dependency from grub-
  efi-*-bin back onto grub-efi-amd64/grub-efi-amd64/signed/grub-pc.

  almost as if the top level packages should simply have a file trigger
  on modules directory to trigger upgrade logic to execute grub-install.

  also feel iffy about the fact that -signed ships efi apps; -signed-bin
  ships modules; and -signed-dbg ships debug ones. collapsing them all
  into one will break the multiarch-foreign constraint on the unsigned
  -bin packages.

  I guess question remains if i should add file-triggers in the grub-pc
  & grub-efi-arm64|amd64-signed packages.

  The advantage of file-trigger would be that grub-efi-*-signed packages
  no longer need to ship any maitaniner scripts, and can be multiarch
  foreign providing modules & efi apps (and dbg modules separate).

  [Test Case]

   * Upgrade to new grub-efi-amd64-bin and grub-efi-amd64-signed
  packages

   * Observe that system boots, one can use grub-mkimage / grub-mkrescue
  without issues.

  [Where problems could occur]

   * The binaries shipped by -signed packages are innert, they are
  bootloader binaries only. The only compatibility that has to be
  maintained is within the userspace tooling - specifically maintainer
  scripts, and file names and locations.

  [Other Info]

   * See all the bug reports that grub can't be installed or upgraded
  when people use -proposed.

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