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