[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