On Sat, Mar 02, 2019 at 11:52:05AM +0100, Christian Kastner wrote: > On 02.03.19 06:42, Steve Langasek wrote: > > On Sun, Feb 24, 2019 at 05:39:30PM +0100, Christian Kastner wrote: > >> The logs don't offer that much, so I was planning to upload a 1.6-5 soon > >> that also saves away all the test artifacts for analysis (it still FTBFS > >> on alpha, for example).
> Side note: saving away the artifacts in $AUTOPKGTEST_ARTIFACTS > apparently didn't work on Ubuntu's side; the artifacts tarball only > contains the usual log files. I think this is because your autopkgtest is 'set -e', so the cp command is never reached when the tests fail, making it decidedly less useful. Manually running the tests in an armhf container, here is the detailed output in keyctl/padd/useradd/test.out: [...] +++ ADD LARGE USER KEY dd if=/dev/zero count=1 bs=32767 | keyctl padd user large @s add_key: Disk quota exceeded === FAILED === Session Keyring 840546527 --alswrv 0 0 keyring: RHTS/keyctl/4251 ============== keyctl pipe no | md5sum | cut -c1-32 d41d8cd98f00b204e9800998ecf8427e === FAILED === Session Keyring 840546527 --alswrv 0 0 keyring: RHTS/keyctl/4251 ============== +++ CLEAR KEYRING keyctl clear @s ++++ FINISHED TEST: FAIL This matches your analysis that there is a quota problem. > > I've synced keyutils 1.6-5 (manually, since we're past feature freeze for > > Ubuntu 19.04) and the tests have rerun, still failing on armhf. > > http://autopkgtest.ubuntu.com/packages/k/keyutils/disco/armhf > Thanks for that! > Short version: The test defines the needs-root restriction; are you > absolutely positive that this is satisfied in your test environment? > Because the results seem to point to the contrary. I suspect the issue here is that the containers are non-privileged (i.e. using user namespaces), so even though the tests are run as "root" in the container, they don't have /real/ root on the kernel and therefore the maxbytes limit applies instead of the root_maxbytes limit. The definition of the needs-root restriction is certainly ambiguous wrt it needs to be uid 0 on the root user namespace. And in any case, this isn't something that Ubuntu is going to be able to change anytime soon - and it's not uncommon for containers to be unprivileged. So I would suggest that this test might be more suitable for the machine-isolation test set. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ [email protected] [email protected]
signature.asc
Description: PGP signature
