[Bug 1878541] Re: Grub fails to load kernel from squashfs if mem < 1500mb

[Launchpad Bug Tracker]

This bug was fixed in the package grub2 - 2.04-1ubuntu26.3

---------------
grub2 (2.04-1ubuntu26.3) focal; urgency=medium

  * 2.04-1ubuntu27 and 2.04-1ubuntu28 folded together for focal
  * debian/patches/ubuntu-flavour-order.patch:
    - Add a (hidden) GRUB_FLAVOUR_ORDER setting that can mark certain kernel
      flavours as preferred, and specify an order between those preferred
      flavours (LP: #1882663)
  * debian/patches/ubuntu-zfs-enhance-support.patch:
    - Use version_find_latest for ordering kernels, so it also supports
      the GRUB_FLAVOUR_ORDER setting.
  * debian/patches/ubuntu-dont-verify-loopback-images.patch:
    - disk/loopback: Don't verify loopback images (LP: #1878541),
      Thanks to Chris Coulson for the patch
  * debian/patches/ubuntu-recovery-dis_ucode_ldr.patch
    - Pass dis_ucode_ldr to kernel for recovery mode (LP: #1831789)
  * debian/patches/ubuntu-add-initrd-less-boot-fallback.patch:
    - Merge changes from xnox to fix multiple initrds support (LP: #1878705)
  * debian/patches/ubuntu-clear-invalid-initrd-spacing.patch:
    - Remove, no longer needed thanks to xnox's patch
  * Ensure that grub-multi-install can always find templates (LP: #1879948)

 -- Julian Andres Klode <juliank at ubuntu.com>  Mon, 17 Aug 2020 16:04:31
+0200

** Changed in: grub2 (Ubuntu Focal)
       Status: Fix Committed => Fix Released

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

Title:
  Grub fails to load kernel from squashfs if mem < 1500mb

Status in snapd:
  In Progress
Status in grub2 package in Ubuntu:
  Fix Released
Status in grub2 source package in Focal:
  Fix Released
Status in grub2 source package in Groovy:
  Fix Released

Bug description:
  [Impact]

   * loopback command uses too much ram, resulting in OOM on small
  machines

  [Test Case]

   * Download & Copy kernel.snap from amd64 pc image onto ESP
  partitition

   * Boot VM with secureboot, uefi and tpm and drop into grub recovery
  shell

   * observe ram usage of the machine (for example by using virt-manager
  graphs)

   * execute "loopback loop0 /path/to/kernel.snap"

   * observe ram usage of the machine again.

   * The RAM usage should stay almost constant with the patched grub
  just like it did in bionic. If it grows by the size of the kernel.snap
  (~500MB+), it is booting using buggy grub as shipped in focal GA.

  [Regression Potential]

   * This patch changes UEFI secureboot verifier behaviour for the
  loopback command. The whole loopback file is no longer read & stored
  into memory.

  This changes the PCR values. However Ubuntu has not yet been using or
  sealing against that PCR value. Also normally, on every kernel/grub
  update, the same PCR value is changed. Thus normal resealing procedure
  after a grub update would accommodate for this change of the PCR
  value.

  The loopback devices as a whole are no longer measured into TPM and
  cannot be attested. The resurrect such behavior, there is upstream
  design plan to allow storing hashes of all blocks and validate them
  with reduced memory requirement. Currently this is deemed out of
  scope, and of low interest/priority.

  [Other Info]

  [Original bug report]

  Booting a uc20 system fails early currently. The image used was:
  http://cdimage.ubuntu.com/ubuntu-core/20/beta/20200513.2/

  Attached is a screenshot of the debug output.

  This appears to be some sort of regression with grub in 20.04 or with
  UEFI grub - this used to work in uc18.

  Note that there is memory < 1500mb

To manage notifications about this bug go to:
https://bugs.launchpad.net/snapd/+bug/1878541/+subscriptions