systemd autopkgtest 'storage' fails adding/rmmoding scsi_debug

Bug #1829347 reported by Dan Streetman
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
systemd (Debian)
Fix Released
Unknown
systemd (Ubuntu)
Won't Fix
Medium
Unassigned
Bionic
Won't Fix
Medium
Unassigned
Cosmic
Won't Fix
Medium
Unassigned
Disco
Won't Fix
Medium
Unassigned
Eoan
Won't Fix
Medium
Unassigned

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.

[other info]

fixing test case that generally causes the failed rmmod in bug 1831459

Dan Streetman (ddstreet)
Changed in systemd (Ubuntu Eoan):
assignee: nobody → Dan Streetman (ddstreet)
Changed in systemd (Ubuntu Disco):
assignee: nobody → Dan Streetman (ddstreet)
Changed in systemd (Ubuntu Cosmic):
assignee: nobody → Dan Streetman (ddstreet)
Changed in systemd (Ubuntu Bionic):
assignee: nobody → Dan Streetman (ddstreet)
Changed in systemd (Ubuntu Eoan):
status: New → In Progress
Changed in systemd (Ubuntu Disco):
status: New → In Progress
Changed in systemd (Ubuntu Cosmic):
status: New → In Progress
Changed in systemd (Ubuntu Bionic):
status: New → In Progress
Changed in systemd (Ubuntu Eoan):
importance: Undecided → Medium
Changed in systemd (Ubuntu Disco):
importance: Undecided → Medium
Changed in systemd (Ubuntu Cosmic):
importance: Undecided → Medium
Changed in systemd (Ubuntu Bionic):
importance: Undecided → Medium
description: updated
tags: added: ddstreet-next
tags: added: id-5ccb0d8d44da805739b5de37
Revision history for this message
Dimitri John Ledkov (xnox) wrote :

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.

Revision history for this message
Dimitri John Ledkov (xnox) wrote :

The addition of the cryptsetup.target apply in the fstab test case is also wrong.
We are trying to test that automatic apply of local-fs.target correctly triggers the cryptsetup mounting as a dependency, without any special cryptsetup.target poking first.

Changed in systemd (Ubuntu Eoan):
status: In Progress → Won't Fix
Revision history for this message
Dan Streetman (ddstreet) wrote :

> 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.

Dan Streetman (ddstreet)
Changed in systemd (Ubuntu Eoan):
assignee: Dan Streetman (ddstreet) → nobody
Changed in systemd (Ubuntu Disco):
assignee: Dan Streetman (ddstreet) → nobody
Changed in systemd (Ubuntu Cosmic):
assignee: Dan Streetman (ddstreet) → nobody
Changed in systemd (Ubuntu Bionic):
assignee: Dan Streetman (ddstreet) → nobody
Changed in systemd (Ubuntu):
assignee: Dan Streetman (ddstreet) → nobody
status: In Progress → New
Changed in systemd (Ubuntu Bionic):
status: In Progress → New
Changed in systemd (Ubuntu Cosmic):
status: In Progress → New
Changed in systemd (Ubuntu Disco):
status: In Progress → New
tags: removed: ddstreet-next
Changed in systemd (Ubuntu Disco):
status: New → Incomplete
Changed in systemd (Ubuntu Cosmic):
status: New → Incomplete
Changed in systemd (Ubuntu Bionic):
status: New → Incomplete
Dan Streetman (ddstreet)
description: updated
Changed in systemd (Debian):
status: Unknown → New
Dan Streetman (ddstreet)
Changed in systemd (Ubuntu Disco):
status: Incomplete → Won't Fix
Changed in systemd (Ubuntu Cosmic):
status: Incomplete → Won't Fix
Changed in systemd (Ubuntu Bionic):
status: Incomplete → Won't Fix
Changed in systemd (Ubuntu):
status: New → Won't Fix
Changed in systemd (Debian):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.