Ok, looking at the CI docs Andres pointed me at, we do usually workaround this by setting the suid bit on the qemu-bridge-helper executable, and dpkg stat-overriding it so it persists across package upgrades.
The docs point at /usr/lib/qemu-bridge-helper which is now a symlink to /usr/lib/qemu/qemu-bridge-helper, so perhaps that's why the problems started (and there was indeed a qemu upload on Apr 20: https://launchpa d.net/ubuntu/+source/qemu/1:2.5+dfsg-5ubuntu10.11). It seems as if autopkgtest could be improved to start up libvirt instances in a way that tells libvirtd to kick off the apparmor profile creation for the domain, but I am dropping this (for now). Cheers, Danilo У чет, 27. 04 2017. у 12:09 +0200, Danilo Šegan пише: > It seems libvirt is expected to run virt-aa-helper to create an > AppArmor profile for each domain and put a file into > /etc/apparmor.d/libvirt/DOMAIN-UUID based on TEMPLATE.qemu in the > same > directory. > > For some reason, this does not seem to happen (or it does not apply) > when autopkgtest is used, so it would be useful to investigate > further > with a proper shell (I've did my digging with "script console" from > within the Jenkins UI). > > Since I am just joining the MAAS team, I'll wait for someone more > experienced with our CI infrastructure to come up so I don't mess > something up (eg. slave rebuild process needs to be fixed too, if > it's > not manual). > > Cheers, > Danilo > > У чет, 27. 04 2017. у 11:19 +0200, Danilo Šegan пише: > > > > Hi all, > > > > It seems MAAS CI has started failing recently with the following: > > > > failed to create tun device: Operation not permitted > > qemu-system-x86_64:/home/ubuntu/workspace/maas-xenial-trunk/maas- > > ci- > > config/etc/region.cfg:3: bridge helper failed > > autopkgtest-virt-qemu: DBG: cleanup... > > <VirtSubproc>: failure: Timed out waiting for /tmp/autopkgtest- > > virt- > > qemu.hekftn7o/ttyS0 socket > > > > See eg. > > > > http://162.213.35.104:8080/job/maas-xenial-trunk/1216/console > > http://162.213.35.104:8080/job/maas-xenial-trunk-manual-juju/262/co > > ns > > ole > > http://162.213.35.104:8080/job/arm64_firmware_update/32/console > > > > > > region.cfg referenced above on our HP-DL360-Gen9 slave > > (http://162.213.35.104:8080/computer/HP-DL360-Gen9/) is the > > following: > > > > ----- 8< ----------- 8< ----- > > # qemu config file > > > > [net] > > type = "bridge" > > vlan = "3" > > br = "br2" > > helper = "/usr/lib/qemu-bridge-helper" > > > > [net] > > type = "nic" > > model = "virtio" > > macaddr = "DE:AD:BE:EF:6B:B3" > > vlan = "3" > > ----- 8< ----------- 8< ----- > > > > (pulled from maas-ci-config branch, where it has not changed since > > January 2017). > > > > > > I've so far worked-around it by setting suid bit on > > /usr/lib/qemu/qemu- > > bridge-helper (the above is just a symlink to this), and the > > following > > job went past that on to running tests: > > > > http://162.213.35.104:8080/job/maas-xenial-trunk/1217/console > > > > I am looking into why apparmor configuration from libvirt-bin > > package > > is not working in this case so I can drop the workaround and fix it > > properly. > > > > Cheers, > > Danilo > > -- Maas-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/maas-devel
