Failing to remove the module, means the testcase / systemd has failed.

Which has been diagnosed and narrowed down to a bug in systemd.

Whilst the proposed improvements to the test case are ok, they make it
skip a lot more without making it more fool proof.

Ideally, I'd like to make the testcase more resilient and enforce more.
Thus failing to remove the module should still be a hard failure.

And upon starting the test case we do need to re-insert the module, as
otherwise LUKS2 header creation would fail (that affects disco+ only).

I do like the add_host usage, but I wonder if it's best be used with
udevadm settle calls, rather than manual tight loops.

-- 
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/1829347

Title:
  systemd autopkgtest 'storage' fails adding/rmmoding scsi_debug

Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Cosmic:
  In Progress
Status in systemd source package in Disco:
  In Progress
Status in systemd source package in Eoan:
  In Progress
Status in systemd package in Debian:
  Unknown

Bug description:
  [impact]

  systemd autopkgtest fails

  [test case]

  run systemd autopkgtest, check for output like:

  LUKS device with "tmp" option ... rmmod: ERROR: Module scsi_debug is in use
  FAIL

  ======================================================================
  FAIL: test_luks_tmp (__main__.CryptsetupTest)
  LUKS device with "tmp" option
  ----------------------------------------------------------------------
  Traceback (most recent call last):
    File "/tmp/autopkgtest.It858Q/build.e7O/src/debian/tests/storage", line 59, 
in setUp
      self.fail('%s exists already' % self.plaintext_dev)
  AssertionError: /dev/mapper/testcrypt1 exists already

  or for older releases something like:

  autopkgtest [19:27:26]: test storage: [-----------------------
  modprobe: FATAL: Module scsi_debug not found in directory 
/lib/modules/4.18.0-1011-kvm
  ERROR

  ======================================================================
  ERROR: setUpClass (__main__.CryptsetupTest)
  ----------------------------------------------------------------------
  Traceback (most recent call last):
    File "/tmp/autopkgtest.azsL0q/build.Hbd/src/debian/tests/storage", line 21, 
in setUpClass
      subprocess.check_call(['modprobe', 'scsi_debug'])
    File "/usr/lib/python3.6/subprocess.py", line 291, in check_call
      raise CalledProcessError(retcode, cmd)
  subprocess.CalledProcessError: Command '['modprobe', 'scsi_debug']' returned 
non-zero exit status 1.

  
  this has attempted to be fixed in disco/eoan so the output is a bit different 
across different releases, but all of them have the common point of failing to 
modprobe or rmmod the scsi_debug module, which by itself doesn't indicate a 
failure.

  [regression potential]

  low; this is fixing a testcase only.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1829347/+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

Reply via email to