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

[Scott Moser]

For the cloud-initramfs-tools upload, I'm provding the following as a SRU template.
Rather than updating the description above.

=== Begin SRU Tempate cloud-initramfs-tools ===
[Impact]
The designed purpose of cloud-initramfs-copymods is to copy modules
from the initramfs to /lib/modules/<uname -r> if there are not any modules
there.  The reasoning is that if there are no modules in the root
filesystem then it is better to have whatever modules were in the initramfs
than no modules at all.

This is accomplished by mounting a tmpfs over /lib/modules and then
putting the contents there.

The problem as seen in this bug is that if there is no /lib/modules directory
in the root image, then we can't mount the tmpfs over the top.

The solution provided for this package was to add the directory to
debian/dirs.  Thus, making the directory created and "owned" by
cloud-initramfs-copymods package.  Wherever it is installed, the /lib/modules
directory will then be present.

[Test Case]
The simplest test case is to just install the package and then:

  $ dpkg -S /lib/modules | fmt --width=1 | grep cloud-initramfs-copymods

Expected output is:

  $ dpkg -S /lib/modules | fmt --width=1 | grep cloud-initramfs-copymods
  cloud-initramfs-copymods,

if cloud-initramfs-copymods is not listed (with or without the trailing ',')
then the fix is not present.

[Regression Potential]
There should be extremely low potential here for regression.
There are already multiple packages (linux-*) that include /lib/modules
in their list of files so simply having multiple packages own that path
is known not to be a problem.

=== End SRU Tempate cloud-initramfs-tools ===

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

Status in cloud-images:
  Triaged
Status in MAAS:
  Triaged
Status in cloud-initramfs-tools package in Ubuntu:
  Fix Released
Status in livecd-rootfs package in Ubuntu:
  Fix Released
Status in open-iscsi package in Ubuntu:
  Confirmed
Status in cloud-initramfs-tools source package in Xenial:
  Fix Committed
Status in livecd-rootfs source package in Xenial:
  Invalid
Status in open-iscsi source package in Xenial:
  Confirmed
Status in cloud-initramfs-tools source package in Bionic:
  Fix Committed
Status in livecd-rootfs source package in Bionic:
  Fix Committed
Status in open-iscsi source package in Bionic:
  Confirmed
Status in cloud-initramfs-tools source package in Cosmic:
  Fix Released
Status in livecd-rootfs source package in Cosmic:
  Fix Released
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 from the initramfs to the real root via cloud-
  initramfs-copymods package.

   * This affects users of our stable release images available from http
  ://cloud-images.ubuntu.com.

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

  [Test Case]

   * Download http://cloud-images.ubuntu.com/bionic/current/bionic-
  server-cloudimg-amd64.squashfs

   * Unpack it via `sudo unsquashfs bionic-server-cloudimg-
  amd64.squashfs`

   * Inspect the unpacked root filesystem and find that '/lib/modules'
  is missing.

   * Install local build scripts as described at
  https://github.com/chrisglass/ubuntu-old-fashioned (note: you will
  need ubuntu-old-fashioned master for cosmic)

  * Re-build the images using the updated livecd-rootfs package.

  * Unpack the resulting livecd.ubuntu-cpc.squashfs artifact using
  unsquashfs again.

  * Inspect the unpacked root filesystem and find that '/lib/modules'
  exists.

  * It is pure luck that package purges which are done analogously in
  Cosmic image builds do not remove '/lib/modules', hence this fix is
  introduced there, as well.

  * Xenial is not affected.

  * Test builds were carried out for Cosmic and Bionic with the expected
  results.

  [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. See also:

  https://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/bionic-
  proposed/revision/1678

  https://bazaar.launchpad.net/~ubuntu-core-dev/livecd-
  rootfs/trunk/revision/1681

   * Packaging tools should not take offense at the existence of a
  directory, even if it was not part of a package. So potential for
  unforseeable regressions is very low.

  ===ORIGINAL BUG DESCRIPTION===

  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