> Failing to remove the module, means the testcase / systemd has failed.
well, not if the module is built-in > Whilst the proposed improvements to the test case are ok, they make it skip a lot more isn't the entire test currently skipped if the module is already loaded? ;) but i get your point, it skips the test if 1) scsi_debug isn't available, 2) scsi_debug add_host interface doesn't work right, 3) scsi_debug adapter* subdir count is != 1 (instead of previously, failing the test) I don't think any of those should cause a test failure, but if you think they should they can change from skiptest to assert. > 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). why will it fail without module re-insertion? It doesn't in my test runs. > 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. I don't think the add_host loops are needed at all; I only added them because there's existing (infinite) loop waiting for the glob to match. -- 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: Won't Fix 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
