| 2018-09-17 10:16:23 |
Blake Rouse |
bug |
|
|
added bug |
| 2018-09-18 08:53:13 |
Blake Rouse |
bug task added |
|
open-iscsi |
|
| 2018-09-18 08:53:28 |
Blake Rouse |
bug task deleted |
open-iscsi |
|
|
| 2018-09-18 08:54:10 |
Blake Rouse |
bug task added |
|
open-iscsi (Ubuntu) |
|
| 2018-09-19 10:02:59 |
Scott Moser |
open-iscsi (Ubuntu): status |
New |
Confirmed |
|
| 2018-09-19 10:03:02 |
Scott Moser |
open-iscsi (Ubuntu): importance |
Undecided |
Low |
|
| 2018-09-19 10:03:12 |
Scott Moser |
bug task added |
|
cloud-images |
|
| 2018-09-19 10:03:21 |
Scott Moser |
cloud-images: status |
New |
Triaged |
|
| 2018-09-19 10:03:24 |
Scott Moser |
cloud-images: importance |
Undecided |
High |
|
| 2018-09-19 20:13:14 |
Scott Moser |
cloud-images: importance |
High |
Critical |
|
| 2018-09-20 07:08:57 |
Dimitri John Ledkov |
bug task added |
|
livecd-rootfs (Ubuntu) |
|
| 2018-09-20 07:09:10 |
Dimitri John Ledkov |
nominated for series |
|
Ubuntu Bionic |
|
| 2018-09-20 07:09:10 |
Dimitri John Ledkov |
bug task added |
|
open-iscsi (Ubuntu Bionic) |
|
| 2018-09-20 07:09:10 |
Dimitri John Ledkov |
bug task added |
|
livecd-rootfs (Ubuntu Bionic) |
|
| 2018-09-20 07:09:10 |
Dimitri John Ledkov |
nominated for series |
|
Ubuntu Cosmic |
|
| 2018-09-20 07:09:10 |
Dimitri John Ledkov |
bug task added |
|
open-iscsi (Ubuntu Cosmic) |
|
| 2018-09-20 07:09:10 |
Dimitri John Ledkov |
bug task added |
|
livecd-rootfs (Ubuntu Cosmic) |
|
| 2018-09-20 07:09:10 |
Dimitri John Ledkov |
nominated for series |
|
Ubuntu Xenial |
|
| 2018-09-20 07:09:10 |
Dimitri John Ledkov |
bug task added |
|
open-iscsi (Ubuntu Xenial) |
|
| 2018-09-20 07:09:10 |
Dimitri John Ledkov |
bug task added |
|
livecd-rootfs (Ubuntu Xenial) |
|
| 2018-09-20 07:10:01 |
Dimitri John Ledkov |
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. |
#! NB Foundations coding day task !#
[Impact]
* An explanation of the effects of the bug on users and
* justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[Test Case]
* detailed instructions how to reproduce the bug
* 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.
* 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
===
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. |
|
| 2018-09-20 07:41:44 |
Francis Ginther |
livecd-rootfs (Ubuntu Xenial): status |
New |
Invalid |
|
| 2018-09-20 08:18:27 |
Tobias Koch |
description |
#! NB Foundations coding day task !#
[Impact]
* An explanation of the effects of the bug on users and
* justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[Test Case]
* detailed instructions how to reproduce the bug
* 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.
* 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
===
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. |
[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. |
|
| 2018-09-20 08:29:26 |
Tobias Koch |
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. |
[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`
* 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. |
|
| 2018-09-20 08:30:30 |
Tobias Koch |
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]
* 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 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. |
[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`
* 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. |
|
| 2018-09-20 08:31:04 |
Tobias Koch |
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]
* 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. |
[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 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. |
|
| 2018-09-20 08:41:34 |
Tobias Koch |
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 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. |
[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 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.
[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. |
|
| 2018-09-20 08:42:59 |
Tobias Koch |
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 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.
[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. |
[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 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.
[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.
===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. |
|
| 2018-09-20 08:44:18 |
Tobias Koch |
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 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.
[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.
===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. |
[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 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.
* 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. |
|
| 2018-09-20 08:46:30 |
Tobias Koch |
attachment added |
|
debdiff for Cosmic. https://bugs.launchpad.net/cloud-images/+bug/1792905/+attachment/5190909/+files/livecd-rootfs-cosmic.diff |
|
| 2018-09-20 08:47:25 |
Tobias Koch |
attachment added |
|
debdiff for Bionic. https://bugs.launchpad.net/cloud-images/+bug/1792905/+attachment/5190910/+files/livecd-rootfs-bionic.diff |
|
| 2018-09-20 08:56:41 |
Tobias Koch |
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 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.
* 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. |
[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 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. |
|
| 2018-09-20 08:57:42 |
Ubuntu Foundations Team Bug Bot |
tags |
|
patch |
|
| 2018-09-20 08:57:50 |
Ubuntu Foundations Team Bug Bot |
bug |
|
|
added subscriber Ubuntu Sponsors Team |
| 2018-09-20 09:23:47 |
Scott Moser |
open-iscsi (Ubuntu Xenial): importance |
Undecided |
Low |
|
| 2018-09-20 09:23:47 |
Scott Moser |
open-iscsi (Ubuntu Xenial): status |
New |
Confirmed |
|
| 2018-09-20 09:24:02 |
Scott Moser |
open-iscsi (Ubuntu Bionic): importance |
Undecided |
Low |
|
| 2018-09-20 09:24:02 |
Scott Moser |
open-iscsi (Ubuntu Bionic): status |
New |
Confirmed |
|
| 2018-09-20 09:26:22 |
Scott Moser |
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 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. |
[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. |
|
| 2018-09-20 09:31:40 |
Robert C Jennings |
bug task added |
|
cloud-initramfs-tools (Ubuntu) |
|
| 2018-09-20 09:36:03 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~rcj/cloud-initramfs-tools/+git/cloud-initramfs-tools/+merge/355409 |
|
| 2018-09-20 11:38:40 |
Dimitri John Ledkov |
livecd-rootfs (Ubuntu Cosmic): status |
New |
Fix Committed |
|
| 2018-09-20 11:38:51 |
Dimitri John Ledkov |
livecd-rootfs (Ubuntu Bionic): status |
New |
In Progress |
|
| 2018-09-20 11:43:57 |
Launchpad Janitor |
branch linked |
|
lp:livecd-rootfs |
|
| 2018-09-20 12:23:09 |
Steve Langasek |
summary |
[2.5] iSCSI systemd services fails and blocks for 1 min 30 secconds |
[2.5] iSCSI systemd services fails and blocks for 1 min 30 seconds |
|
| 2018-09-20 12:32:30 |
Francis Ginther |
tags |
patch |
id-5ba344692475d642386a6bcb patch |
|
| 2018-09-20 12:46:59 |
Scott Moser |
cloud-initramfs-tools (Ubuntu Cosmic): importance |
Undecided |
High |
|
| 2018-09-20 12:46:59 |
Scott Moser |
cloud-initramfs-tools (Ubuntu Cosmic): status |
New |
Confirmed |
|
| 2018-09-20 12:47:29 |
Scott Moser |
cloud-initramfs-tools (Ubuntu Bionic): importance |
Undecided |
High |
|
| 2018-09-20 12:47:29 |
Scott Moser |
cloud-initramfs-tools (Ubuntu Bionic): status |
New |
Confirmed |
|
| 2018-09-20 12:47:47 |
Scott Moser |
cloud-initramfs-tools (Ubuntu Xenial): importance |
Undecided |
High |
|
| 2018-09-20 12:47:47 |
Scott Moser |
cloud-initramfs-tools (Ubuntu Xenial): status |
New |
Confirmed |
|
| 2018-09-20 13:11:30 |
Adam Conrad |
livecd-rootfs (Ubuntu Bionic): status |
In Progress |
Fix Committed |
|
| 2018-09-20 13:11:33 |
Adam Conrad |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2018-09-20 13:11:35 |
Adam Conrad |
bug |
|
|
added subscriber SRU Verification |
| 2018-09-20 13:11:38 |
Adam Conrad |
tags |
id-5ba344692475d642386a6bcb patch |
id-5ba344692475d642386a6bcb patch verification-needed verification-needed-bionic |
|
| 2018-09-20 13:13:35 |
Adam Conrad |
removed subscriber Ubuntu Sponsors Team |
|
|
|
| 2018-09-20 13:21:55 |
Launchpad Janitor |
cloud-initramfs-tools (Ubuntu Cosmic): status |
Confirmed |
Fix Released |
|
| 2018-09-20 13:42:21 |
Scott Moser |
cloud-initramfs-tools (Ubuntu Xenial): assignee |
|
Scott Moser (smoser) |
|
| 2018-09-20 13:42:33 |
Scott Moser |
cloud-initramfs-tools (Ubuntu Xenial): status |
Confirmed |
In Progress |
|
| 2018-09-20 13:42:49 |
Scott Moser |
cloud-initramfs-tools (Ubuntu Bionic): status |
Confirmed |
In Progress |
|
| 2018-09-20 13:42:49 |
Scott Moser |
cloud-initramfs-tools (Ubuntu Bionic): assignee |
|
Scott Moser (smoser) |
|
| 2018-09-20 17:15:27 |
Launchpad Janitor |
livecd-rootfs (Ubuntu Cosmic): status |
Fix Committed |
Fix Released |
|
| 2018-10-01 17:41:15 |
Adam Conrad |
cloud-initramfs-tools (Ubuntu Bionic): status |
In Progress |
Fix Committed |
|
| 2018-10-01 17:42:00 |
Adam Conrad |
cloud-initramfs-tools (Ubuntu Xenial): status |
In Progress |
Fix Committed |
|
| 2018-10-01 17:42:08 |
Adam Conrad |
tags |
id-5ba344692475d642386a6bcb patch verification-needed verification-needed-bionic |
id-5ba344692475d642386a6bcb patch verification-needed verification-needed-bionic verification-needed-xenial |
|
| 2018-10-02 16:03:27 |
Scott Moser |
attachment added |
|
log of verification of cloud-initramfs-tools fix in xenial. https://bugs.launchpad.net/ubuntu/xenial/+source/cloud-initramfs-tools/+bug/1792905/+attachment/5195942/+files/1792905-copymods-xenial-verify.log |
|
| 2018-10-02 16:09:06 |
Scott Moser |
attachment added |
|
log of verification of cloud-initramfs-tools fix in bionic https://bugs.launchpad.net/ubuntu/xenial/+source/cloud-initramfs-tools/+bug/1792905/+attachment/5195945/+files/1792905-copymods-bionic-verify.log |
|
| 2018-10-02 16:09:57 |
Scott Moser |
tags |
id-5ba344692475d642386a6bcb patch verification-needed verification-needed-bionic verification-needed-xenial |
id-5ba344692475d642386a6bcb patch verification-done-xenial verification-needed verification-needed-bionic |
|
| 2018-10-02 16:12:06 |
Scott Moser |
tags |
id-5ba344692475d642386a6bcb patch verification-done-xenial verification-needed verification-needed-bionic |
id-5ba344692475d642386a6bcb patch verification-done-bionic verification-done-xenial verification-needed |
|
| 2018-10-02 19:24:02 |
Steve Langasek |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2018-10-02 19:34:06 |
Launchpad Janitor |
livecd-rootfs (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2018-10-02 21:20:48 |
Andres Rodriguez |
maas: status |
Triaged |
Invalid |
|
| 2018-10-08 10:29:56 |
Launchpad Janitor |
cloud-initramfs-tools (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2018-10-08 10:44:14 |
Launchpad Janitor |
cloud-initramfs-tools (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2019-01-07 14:30:30 |
Scott Moser |
open-iscsi (Ubuntu): status |
Confirmed |
Invalid |
|
| 2019-01-07 14:30:43 |
Scott Moser |
open-iscsi (Ubuntu Xenial): status |
Confirmed |
Invalid |
|
| 2019-01-07 14:30:59 |
Scott Moser |
open-iscsi (Ubuntu Bionic): status |
Confirmed |
Invalid |
|
| 2019-01-07 14:31:09 |
Scott Moser |
open-iscsi (Ubuntu Cosmic): status |
Confirmed |
Invalid |
|
| 2019-01-07 14:31:56 |
Scott Moser |
cloud-images: status |
Triaged |
Fix Released |
|
