apparmor mult_mount regression test fails in eoan

[Seth Forshee]

In running adt testing on 5.2-based kernels for eoan, I'm seeing failures from the apparmor mult_mount regression test. Running the test case manually with -x yields:

 + dd if=/dev/zero of=/tmp/sdtest.2210-22387-i6UxxQ/image.ext3 bs=4096 count=20
 + mkfs.ext2 -F -m 0 -N 10 /tmp/sdtest.2210-22387-i6UxxQ/image.ext3
 ++ error_handler
 ++ fatalerror 'Unexpected shell error. Run with -x to debug'

Running the following manually in a shell also fails in eoan with the 5.0 kernel copied forward from disco, while it passes in disco:

 $ uname -a
 Linux ee-apparmor 5.0.0-17-generic #18-Ubuntu SMP Tue Jun 4 15:34:08 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
 $ dd if=/dev/zero of=test.img bs=4096 count=20
 20+0 records in
 20+0 records out
 81920 bytes (82 kB, 80 KiB) copied, 0.000406443 s, 202 MB/s
 $ mkfs.ext2 -F -m 0 -N 10 test.img
 mke2fs 1.45.2 (27-May-2019)
 test.img: Not enough space to build proposed filesystem while setting up superblock

So this seems likely to be due to some change with mke2fs; not sure if this is a regression there or if the test was getting away with doing something invalid.

[Steve Beattie (sbeattie)]

The issue here is that in LP: #1817097 e2fsprogs was changed to use 4k blocks by default regardless of the created fs size. Changing the command to force a 1012 byte blocksize causes the mkfs.ext2 command to succeed:

  $ dd if=/dev/zero of=/tmp/image.ext3 bs=4096 count=20
  20+0 records in
  20+0 records out
  81920 bytes (82 kB, 80 KiB) copied, 0.00136542 s, 60.0 MB/s
  $ mkfs.ext2 -F -m 0 -N 10 /tmp/image.ext3
  mke2fs 1.45.1 (12-May-2019)
  /tmp/image.ext3: Not enough space to build proposed filesystem while setting up superblock
  $ mkfs.ext2 -F -m 0 -N 10 -b 1024 /tmp/image.ext3
  mke2fs 1.45.1 (12-May-2019)
  Discarding device blocks: done
  Creating filesystem with 80 1k blocks and 16 inodes

  Allocating group tables: done
  Writing inode tables: done
  Writing superblocks and filesystem accounting information: done

There are two ways to solve this:

  1) change the command to force 1024 byte block sizes; the -b argument has existed in e2fsprogs since at least the 1.42 version included in ubuntu 12.04 LTS.

  2) the image was setup to be laughably small to ensure the testsuite could run successfully in relatively small scale environments; we could bump the generated image to 128 blocks (512KB), which would let mkfs succeed while still not excessively consuming space.

[Steve Beattie (sbeattie)]

Fix committed upstream: https://gitlab.com/apparmor/apparmor/commit/7c7a4bc5311d983f2c4316252b830c52a5a0930b and backported to apparmor-2.13.

We can work around this in qa-regression-testing or fix with an apparmor upload.

[Jamie Strandboge (jdstrand)]

This was fixed in 2.13.3-5ubuntu1 which added upstream-tests-mult-mount-bump-size-of-created-disk.patch