Glad to find this discussed and solved already when waking up - thanks Ryan and Steve!
To complete the discussions I'm adding a little reference as on IRC it seemed this question was left open:
"[20:40] <vorlon> rharper: right, I also fundamentally question why the open-iscsi package should hard-code the modules for loading if there's additional configuration required (not necessarily extra packages, but at least non-default config options that should maybe be detected to trigger on-demand module loading)"
I think the history on this is [1] which was converting an old unconditional load (that would do || true, and therefore never make it fail/bad) into something else which instead of the old code had the negative effect that Steve reported here initially.
Glad to find this discussed and solved already when waking up - thanks Ryan and Steve!
To complete the discussions I'm adding a little reference as on IRC it seemed this question was left open:
"[20:40] <vorlon> rharper: right, I also fundamentally question why the open-iscsi package should hard-code the modules for loading if there's additional configuration required (not necessarily extra packages, but at least non-default config options that should maybe be detected to trigger on-demand module loading)"
I think the history on this is [1] which was converting an old unconditional load (that would do || true, and therefore never make it fail/bad) into something else which instead of the old code had the negative effect that Steve reported here initially.
[1]: https:/ /salsa. debian. org/linux- blocks- team/open- iscsi/commit/ 592d3d1f6