mount autopkgtest failure in lxc container

Bug #1656391 reported by Barry Warsaw
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ubuntu Image
Fix Released
Critical
Barry Warsaw

Bug Description

We first saw this failure in zesty-proposed for armhf:

Check that device-mapper is available in the kernel.
Incompatible libdevmapper 1.02.136 (2016-11-05) and kernel driver (unknown version).
device mapper prerequisites not met
/dev/mapper/control: mknod failed: Operation not permitted
Failure to communicate with kernel device-mapper driver.
Check that device-mapper is available in the kernel.
Incompatible libdevmapper 1.02.136 (2016-11-05) and kernel driver (unknown version).
device mapper prerequisites not met

This test was added back in 0.9 and it's been passing on all architectures since then, but started failing in 0.13. At first we thought it was due to a recent change in the armhf architecture, but now I think it's because of a recent-ish change in lxc or the autopkgtest images used for armhf. The reason it only shows up on that architecture is that only the armhf architecture uses lxc containers for its autopkgtests.

It turns out this is reproducible in an amd64 container now too, although the autopkgtest infrastructure doesn't use it.

I'm not yet sure whether it's a missing dependency or some other change in the images, but we can at least rule out armhf specific problems.

Revision history for this message
Barry Warsaw (barry) wrote :
Changed in ubuntu-image:
milestone: none → 0.14
assignee: nobody → Barry Warsaw (barry)
importance: Undecided → Critical
status: New → In Progress
Revision history for this message
Barry Warsaw (barry) wrote :

This passes locally:

autopkgtest build-area/ubuntu-image_0.14+17.04ubuntu1.dsc -- schroot zesty-amd64

This fails locally:

autopkgtest -s build-area/ubuntu-image_0.13+17.04ubuntu2.dsc -- lxd autopkgtest/ubuntu/zesty/amd64

Revision history for this message
Barry Warsaw (barry) wrote :

Okay, so the sweater thread is now laying in a puddle on the floor, the worms have all escaped the can, etc.

From IRC:

<stgraber> barry: note that devmapper itself isn't namespaced, so if the adt
           container is allowed to interact with it, you may well conflict
           with another container and run into surprises [16:13]

which means that technically speaking, the mount adt test should be Restriction: isolation-machine. This will prevent the test from running in lxd container and thus will be skipped on armhf. It will also prevent it from running in a schroot locally (which is what I typically use during development). The test will run in adt-virt-qemu backends so they should run for amd64, i386, and ppc64el.

I still don't know what changed and when on the autopkgtest.ubuntu.com infra since the tests clearly succeeded on armhf until 0.13 was uploaded. I may email ubuntu-devel@ to see if anybody knows, but ultimately it's better to name the correct Restrictions and let the rest sort out naturally.

Revision history for this message
Barry Warsaw (barry) wrote :

My suspicion for what changed: autopkgtest.u.c used to run privileged containers for armhf and was switched to unprivileged containers.

Barry Warsaw (barry)
Changed in ubuntu-image:
status: In Progress → Fix Committed
Barry Warsaw (barry)
Changed in ubuntu-image:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.