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

Martin Pitt martin.pitt at ubuntu.com
Thu Feb 13 07:21:29 UTC 2014


For  the record, this hasn't fully been fixed in Quantal: Quantal's
/etc/kernel/postinst.d/zz-update-grub does NOT have the container check
as introduced in precise's grub2 (1.99-21ubuntu3.9) SRU. This breaks
upgrades from quantal to saucy in containers:

  https://jenkins.qa.ubuntu.com/job/upgrade-ubuntu-quantal-saucy-
desktop-amd64/27/

(I filed bug 1279658 about this and then found this bug when analyzing
it). At this point I'm not sure whether it's still worth SRUing this to
quantal, or whether we just apply a workaround in our testing.

-- 
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 “grub2” source package in Precise:
  Fix Released
Status in “lxc” source package in Precise:
  Invalid
Status in “grub2” source package in Quantal:
  Fix Released
Status in “lxc” source package in Quantal:
  Fix Released

Bug description:
  [Impact] GRUB upgrades fail in containers.
  [Test Case] Upgrade the grub-pc package in a container.
  [Regression Potential] In itself, this postinst fix should be quite safe.  It's possible it won't solve the whole problem - e.g. linux-image-* upgrades calling update-grub - but I wanted to backport just what was in quantal/raring rather than getting creative in an SRU.

  [XXX edit - removed the SRU justification for lxc part.  The proposed solution
  was not safe, and was undone in a later commit.  devtmpfs cannot be mounted
  in a container, because changes under the container's /dev are then
  reflected in the host's /dev.

  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