Hey thanks for subscribing me! We haven't had an LXD update recently (the instances are using LXD from bionic-updates and that's not been changed for a long time). The only things I can think of is that Adam recently deployed a config change to set 'security.nesting=true' on our instances (https://git.launchpad.net /autopkgtest-cloud/commit/?id=b8c9165686c7598b3f1a68aa4684e7f382ad935c), and we recently (last week, while in Paris) dist-upgraded and rebooted them all to pick up a newer kernel (4.15.0-62-generic).
I'm not sure if either of these changes might relate to what you're seeing here - my first suggestion would be talk to the LXD team? If you need help connecting with them, please let me know. Hope that helps. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1845337 Title: Disco autopkgtest @ armhf fails root-unittests -> test-execute -> exec-dynamicuser-statedir.service Status in qemu package in Ubuntu: New Status in systemd package in Ubuntu: New Status in qemu source package in Disco: New Status in systemd source package in Disco: New Bug description: Since the recent few weeks systemd autopkgtest @ armhf @ disco fail [1]. The log is very (very) long and partially interwoven due to concurrent execution. Somewhere in between we see this subcase is the one failing: root-unittests Of this test (which again has many subtests) it is: test-execute And of this again it is (always): I'll attach bad and good case full and stripped logs. The diff of those comes down to just: 1. execute a find in a shell 2. shell exits 3. exec-dynamicuser-statedir.service: Main process exited, code=exited, status=0/SUCCESS vs 3. exec-dynamicuser-statedir.service: Main process exited, code=exited, status=1/FAILURE 4. in the bad case that triggers an assertion The find that fails is: find / -path /var/tmp -o -path /tmp -o -path /proc -o -path /dev/mqueue -o -path /dev/shm -o -path /sys/fs/bpf Good and bad case are the same most recent version systemd/240-6ubuntu5.7. Maybe something is bad in the containers we have for armhf in regard to these paths? Was there any change we'd know of? If there is nothing known, could we force-badtest it to get it out of the way of ongoing migrations? [1]: http://autopkgtest.ubuntu.com/packages/s/systemd/disco/armhf To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1845337/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
