don't short-circuit update-grub kernel postinst hook in containers
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
livecd-rootfs (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Xenial |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
[SRU Justification]
LP: #1060404 was addressed by making the update-grub kernel postinst hook a no-op when running in containers.
We now do all of our livefs builds in containers in Launchpad; this means livefses no longer get a grub config automatically generated with the correct contents when installing a kernel in the target, as they did previously.
The change for LP: #1060404 was described by Colin as a "temporary fix".
We know that update-grub itself now succeeds in the launchpad buildd containers, because we have several points in livefs builds where we are invoking it directly and it does what we expect. And in any containers where update-grub does not work, these same livefs builds will fail anyway.
[Test case]
Run through a standard set of xenial image builds with livecd-rootfs in launchpad, including the private cloud image builds. Confirm that the builds are successful and that the resulting images list the correct contents in /boot/grub/
[Regression potential]
If something else relied on container detection in order to modify its behavior, and is called between the addition and removal of the systemd-detect-virt diversion, it could now behave incorrectly in a container and cause build failures. This is an entirely hypothetical scenario, since all current consumers of (un)divert_grub, and pending users of it, have it very narrowly scoped such that they're only doing update-grub / kernel install operations in between.
prelim feedback is that update-grub does still fail in a lxd container with a stock setup; so we will need to work around this in livecd-rootfs instead.