[Bug 1792905] Re: [2.5] iSCSI systemd services fails and blocks for 1 min 30 secconds

[Tobias Koch]

** Description changed:

- #! NB Foundations coding day task !#
- 
  [Impact]
  
-  * An explanation of the effects of the bug on users and
+  * Affects environments where the base image is read-only but kernel
+ modules are copied to a tempfs or other overlay mounted on /lib/modules.
  
-  * justification for backporting the fix to the stable release.
+  * This affects users of our stable release images.
  
-  * In addition, it is helpful, but not required, to include an
-    explanation of how the upload fixes this bug.
+  * The attached fixes ensure /lib/modules always exists by creating it
+ explicitly instead of relying on it to come from a package.
  
  [Test Case]
  
-  * detailed instructions how to reproduce the bug
+  * TODO...
  
-  * these should allow someone who is not familiar with the affected
-    package to reproduce the bug and verify that the updated package fixes
-    the problem.
+  * these should allow someone who is not familiar with the affected
+    package to reproduce the bug and verify that the updated package fixes
+    the problem.
  
  [Regression Potential]
  
-  * discussion of how regressions are most likely to manifest as a result
- of this change.
+  * This is a fix to a regression. The existence of the directory had
+ previously been ensured, but the mkdir call got lost in recent re-
+ factoring.
  
-  * It is assumed that any SRU candidate patch is well-tested before
-    upload and has a low overall risk of regression, but it's important
-    to make the effort to think about what ''could'' happen in the
-    event of a regression.
- 
-  * This both shows the SRU team that the risks have been considered,
-    and provides guidance to testers in regression-testing the SRU.
- 
- [Other Info]
-  
-  * Anything else you think is useful to include
-  * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
-  * and address these questions in advance
+  * Packaging tools should not take offense at the existence of a
+ directory, even if it was not part of a package at that time. So
+ potential for regressions from this fix is basically zero.
  
  ===
  
  Let me first start with saying MAAS is *not* using iSCSI anymore and is
  *NOT* in this case either.
  
  For some reason now using enlistment, commissioning, and deploying the
  ephemeral environment will block for 1 min 30 seconds waiting for the
  iSCSI daemon to succeed, which it never does.
  
  This increases the boot time drastically.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to livecd-rootfs in Ubuntu.
https://bugs.launchpad.net/bugs/1792905

Title:
  [2.5] iSCSI systemd services fails and blocks for 1 min 30 secconds

Status in cloud-images:
  Triaged
Status in MAAS:
  Triaged
Status in livecd-rootfs package in Ubuntu:
  New
Status in open-iscsi package in Ubuntu:
  Confirmed
Status in livecd-rootfs source package in Xenial:
  Invalid
Status in open-iscsi source package in Xenial:
  New
Status in livecd-rootfs source package in Bionic:
  New
Status in open-iscsi source package in Bionic:
  New
Status in livecd-rootfs source package in Cosmic:
  New
Status in open-iscsi source package in Cosmic:
  Confirmed

Bug description:
  [Impact]

   * Affects environments where the base image is read-only but kernel
  modules are copied to a tempfs or other overlay mounted on
  /lib/modules.

   * This affects users of our stable release images.

   * The attached fixes ensure /lib/modules always exists by creating it
  explicitly instead of relying on it to come from a package.

  [Test Case]

   * TODO...

   * these should allow someone who is not familiar with the affected
     package to reproduce the bug and verify that the updated package fixes
     the problem.

  [Regression Potential]

   * This is a fix to a regression. The existence of the directory had
  previously been ensured, but the mkdir call got lost in recent re-
  factoring.

   * Packaging tools should not take offense at the existence of a
  directory, even if it was not part of a package at that time. So
  potential for regressions from this fix is basically zero.

  ===

  Let me first start with saying MAAS is *not* using iSCSI anymore and
  is *NOT* in this case either.

  For some reason now using enlistment, commissioning, and deploying the
  ephemeral environment will block for 1 min 30 seconds waiting for the
  iSCSI daemon to succeed, which it never does.

  This increases the boot time drastically.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/1792905/+subscriptions