[Bug 1060404] Re: update-grub runs and fails in containers

Launchpad Bug Tracker 1060404 at bugs.launchpad.net
Sun Oct 7 18:47:13 UTC 2012


This bug was fixed in the package grub2 - 2.00-7ubuntu3

---------------
grub2 (2.00-7ubuntu3) quantal; urgency=low

  * If the postinst is running in a container, skip grub-install and all its
    associated questions (LP: #1060404).
  * Merge UEFI secure boot tweaks from Fedora:
    - Don't error on insmod on UEFI/SB, but also don't do any insmodding.
    - Add sleep to the list of modules in the signed image.
  * Move Ubuntu modifications to the Fedora linuxefi patch into separate
    patches, to ease maintenance.
  * Implement secure boot handling policy as outlined by Steve Langasek:
    - Make the linux module call linuxefi when necessary, simplifying
      configuration.  Add the linux module to the signed image.
    - If secure boot is enabled and the kernel is signed, linux will call
      linuxefi to hand over to it without calling ExitBootServices.
    - Otherwise, linux will fall through to previous code, call
      ExitBootServices itself, and boot the kernel normally.
    - Change linuxefi to return GRUB_ERR_ACCESS_DENIED rather than
      GRUB_ERR_INVALID_COMMAND in the case of an invalid signature, to make
      it easier to implement different handling of unsigned kernels in
      future if necessary.
  * Build two images for signing: one with prefix /EFI/BOOT for use on
    removable media, and one with prefix /EFI/ubuntu (and with the lvm,
    mdraid09, and mdraid1x modules added) for use on fixed disks.  Setup
    mostly borrowed from Fedora.
  * Generate configuration for signed UEFI kernels if available.
 -- Colin Watson <cjwatson at ubuntu.com>   Sun, 07 Oct 2012 11:36:29 +0100

** Changed in: grub2 (Ubuntu Quantal)
       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/1060404

Title:
  update-grub runs and fails in containers

Status in “grub2” package in Ubuntu:
  Fix Released
Status in “lxc” package in Ubuntu:
  Fix Released
Status in “upstart” package in Ubuntu:
  Invalid
Status in “grub2” source package in Precise:
  New
Status in “lxc” source package in Precise:
  Triaged
Status in “upstart” source package in Precise:
  New
Status in “grub2” source package in Quantal:
  Fix Released
Status in “lxc” source package in Quantal:
  Fix Released
Status in “upstart” source package in Quantal:
  Invalid

Bug description:
  ==============================
  SRU justification for lxc part:
  1. Impact: update-grub fails, causing apt-get updates to fail if there is a new kernel.
  2. Development fix: modify ubuntu templates to mount devtmpfs before starting container
  3. Stable fix: same as development fix.
  4. Test case:
  	sudo lxc-create -t ubuntu-cloud -n q1
  	sudo lxc-start q1
  	# inside the container, run sudo update-grub
  5. Regression potential: This adds one more mount per container (by default, removable), taking up more memory.
  ==============================
  If grub is installed in a container (as happens, for instance, with the ubuntu-cloud template) then an update of grub or linux-image will cause update-grub to be run.  It tries, finds it can't access the root device, fails, and causes the update to fail.

  It would be better for update-grub to detect that it is in a container
  and simply exit 0, so that the apt-get can succeed.  I'm attaching a
  debdiff which does that.

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




More information about the foundations-bugs mailing list