** Description changed: [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... + * Download http://cloud-images.ubuntu.com/bionic/current/bionic-server- + cloudimg-amd64.squashfs - * 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. + * 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. + + * Do the above for Bionic and Cosmic. [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.
** Description changed: [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] * Download http://cloud-images.ubuntu.com/bionic/current/bionic-server- cloudimg-amd64.squashfs - * Unpack it via `sudo unsquashfs 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 + * 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. * Do the above for Bionic and Cosmic. [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. + directory, even if it was not part of a package. So potential for + unforseeable regressions is very low. === 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. ** Description changed: [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. + * 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. * Do the above for Bionic and Cosmic. [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. So potential for unforseeable regressions is very low. === 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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1792905 Title: [2.5] iSCSI systemd services fails and blocks for 1 min 30 secconds To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1792905/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
