juju.worker.diskmanager goes into ERROR loop inside a container

Bug #1506044 reported by John A Meinel on 2015-10-14
This bug affects 4 people
Affects Status Importance Assigned to Milestone

Bug Description

I believe by default LXC containers are unable to see information about loopback devices (loop requires kernel rights that we don't grant, I guess).

Anyway, if I try to deploy something into an LXC container, and the host has a loopback mount already set up, I end up seeing log spam with:
 ERROR juju.worker.diskmanager lsblk.go:116 error checking if "loop0" is in use: open /dev/loop0: operation not permitted

It seems to trigger on a 30 second loop.

This doesn't seem to trigger the bug:
  juju bootstrap -e amazon [--upload-tools]
  juju ssh 0 -e amazon "truncate -s 10M test.img; mkfs.ext4 test.img; mkdir test; sudo mount -o loop -t ext4 test.img test"
  # Answer "y" when prompted by mkfs.ext4
  juju deploy ubuntu --to lxc:0

I think I'm running into this because I am using a bind mount in the host machine, which confuses the container's machine agent.

This was tested with juju-1.26 master rev be7f6bde

John A Meinel (jameinel) on 2015-10-14
description: updated
description: updated
John A Meinel (jameinel) on 2015-10-14
description: updated
Curtis Hovey (sinzui) on 2015-11-03
Changed in juju-core:
milestone: 1.26-alpha1 → 1.26-alpha2
Changed in juju-core:
milestone: 1.26-alpha2 → 1.26.0
Changed in juju-core:
milestone: 1.26.0 → 2.0-beta5
Changed in juju-core:
milestone: 2.0-beta5 → 2.0-beta4
Changed in juju-core:
milestone: 2.0-beta4 → 2.0.1
affects: juju-core → juju
Changed in juju:
milestone: 2.0.1 → none
milestone: none → 2.0.1
Curtis Hovey (sinzui) on 2016-10-28
Changed in juju:
milestone: 2.0.1 → none
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers