Comment 4 for bug 1783922

Hi Steve,

The node was deployed by our MaaS, we don't build the kernel before testing.

This was tested manually in two ways:
A. with the autotest framework:

  git clone --depth=1 git://kernel.ubuntu.com/ubuntu/autotest-client-tests -b master-next
  git clone --depth=1 git://kernel.ubuntu.com/ubuntu/autotest
  rm -fr autotest/client/tests
  ln -sf ~/autotest-client-tests autotest/client/tests
  AUTOTEST_PATH=/home/ubuntu/autotest sudo -E autotest/client/autotest-local --verbose autotest/client/tests/ubuntu_qrt_apparmor/control

B. Run the python script directlｙ

  # Enable deb-src
  sudo apt-get install -y apparmor apparmor-profiles apparmor-utils apport attr devscripts execstack exim4 gawk git libapparmor-dev libapparmor-perl libcap2-bin libcap-dev libdbus-1-dev libgtk2.0-dev libpam-apparmor netcat pyflakes python3 python3-all-dev python-libapparmor python-pexpect quilt sudo gcc
  git clone --depth 1 https://git.launchpad.net/qa-regression-testing
  cd qa-regression-testing/scripts
  sudo ./test-apparmor.py

I tried several times on this and another KVM　instance, it's 100% reproducible for a fresh node with either method A or B (it looks like the test will pass on second run, not sure if it has anything to do with the test setup process)

Steps:
  1. Run the test either with A or B
  2. Reboot

Everytime when this test hang, it will stuck at the mmap test with operation="profile_load"

This hang (timeout) issue can be found on Azure kernel as well:
https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1763002

The zombie process is affecting the automation.