| 2017-04-19 08:00:07 |
Trent Lloyd |
bug |
|
|
added bug |
| 2017-04-19 08:12:01 |
Trent Lloyd |
attachment added |
|
lp1684039-ibft-dhcp-origin.debdiff https://bugs.launchpad.net/ubuntu/+source/open-iscsi/+bug/1684039/+attachment/4864647/+files/lp1684039-ibft-dhcp-origin.debdiff |
|
| 2017-04-19 08:28:55 |
Ubuntu Foundations Team Bug Bot |
tags |
|
patch |
|
| 2017-04-19 08:29:02 |
Ubuntu Foundations Team Bug Bot |
bug |
|
|
added subscriber Ubuntu Sponsors Team |
| 2017-04-19 11:10:45 |
Dominique Poulain |
bug |
|
|
added subscriber Dominique Poulain |
| 2017-04-19 13:16:51 |
Dan Streetman |
bug |
|
|
added subscriber Dan Streetman |
| 2017-04-25 04:34:59 |
Mathew Hodson |
open-iscsi (Ubuntu): importance |
Undecided |
Medium |
|
| 2017-05-10 18:29:08 |
Trent Lloyd |
attachment added |
|
lp1684039-ibft-dhcp-origin-artful.debdiff https://bugs.launchpad.net/ubuntu/+source/open-iscsi/+bug/1684039/+attachment/4874783/+files/lp1684039-ibft-dhcp-origin-artful.debdiff |
|
| 2017-05-10 18:32:27 |
Trent Lloyd |
tags |
patch |
patch sts-sru-needed |
|
| 2017-05-15 16:56:17 |
Eric Desrochers |
open-iscsi (Ubuntu): assignee |
|
Trent Lloyd (lathiat) |
|
| 2017-05-15 16:56:26 |
Eric Desrochers |
bug |
|
|
added subscriber Eric Desrochers |
| 2017-06-23 08:35:54 |
Trent Lloyd |
nominated for series |
|
Ubuntu Xenial |
|
| 2017-06-23 08:35:54 |
Trent Lloyd |
nominated for series |
|
Ubuntu Artful |
|
| 2017-06-23 08:35:54 |
Trent Lloyd |
nominated for series |
|
Ubuntu Yakkety |
|
| 2017-06-23 08:35:54 |
Trent Lloyd |
nominated for series |
|
Ubuntu Zesty |
|
| 2017-06-23 12:48:30 |
Eric Desrochers |
bug task added |
|
open-iscsi (Ubuntu Artful) |
|
| 2017-06-23 12:48:36 |
Eric Desrochers |
bug task added |
|
open-iscsi (Ubuntu Xenial) |
|
| 2017-06-23 12:48:41 |
Eric Desrochers |
bug task added |
|
open-iscsi (Ubuntu Yakkety) |
|
| 2017-06-23 12:48:46 |
Eric Desrochers |
bug task added |
|
open-iscsi (Ubuntu Zesty) |
|
| 2017-06-23 12:49:00 |
Eric Desrochers |
open-iscsi (Ubuntu Zesty): assignee |
|
Trent Lloyd (lathiat) |
|
| 2017-06-23 12:49:11 |
Eric Desrochers |
open-iscsi (Ubuntu Yakkety): assignee |
|
Trent Lloyd (lathiat) |
|
| 2017-06-23 12:49:24 |
Eric Desrochers |
open-iscsi (Ubuntu Xenial): assignee |
|
Trent Lloyd (lathiat) |
|
| 2017-06-23 12:49:31 |
Eric Desrochers |
open-iscsi (Ubuntu Xenial): importance |
Undecided |
Medium |
|
| 2017-06-23 12:49:33 |
Eric Desrochers |
open-iscsi (Ubuntu Yakkety): importance |
Undecided |
Medium |
|
| 2017-06-23 12:49:34 |
Eric Desrochers |
open-iscsi (Ubuntu Zesty): importance |
Undecided |
Medium |
|
| 2017-06-29 02:53:02 |
Trent Lloyd |
bug watch added |
|
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866213 |
|
| 2017-06-29 02:53:02 |
Trent Lloyd |
bug task added |
|
open-iscsi (Debian) |
|
| 2017-06-29 03:53:58 |
Bug Watch Updater |
open-iscsi (Debian): status |
Unknown |
Confirmed |
|
| 2017-07-03 06:35:00 |
Bug Watch Updater |
open-iscsi (Debian): status |
Confirmed |
Fix Released |
|
| 2017-07-04 15:07:13 |
Eric Desrochers |
open-iscsi (Ubuntu Artful): status |
New |
In Progress |
|
| 2017-07-05 13:19:47 |
Eric Desrochers |
attachment added |
|
artful-open-iscsi_2.0.874-2ubuntu2.debdiff https://bugs.launchpad.net/ubuntu/+source/open-iscsi/+bug/1684039/+attachment/4909731/+files/artful-open-iscsi_2.0.874-2ubuntu2.debdiff |
|
| 2017-07-05 14:48:34 |
Eric Desrochers |
open-iscsi (Ubuntu Artful): assignee |
Trent Lloyd (lathiat) |
Eric Desrochers (slashd) |
|
| 2017-07-05 15:15:51 |
Eric Desrochers |
attachment added |
|
zesty-open-iscsi_2.0.873+git0.3b4b4500-14ubuntu18.debdiff https://bugs.launchpad.net/ubuntu/+source/open-iscsi/+bug/1684039/+attachment/4909854/+files/zesty-open-iscsi_2.0.873+git0.3b4b4500-14ubuntu18.debdiff |
|
| 2017-07-05 15:24:21 |
Eric Desrochers |
attachment added |
|
xenial-open-iscsi_2.0.873+git0.3b4b4500-14ubuntu3.4.debdiff https://bugs.launchpad.net/ubuntu/+source/open-iscsi/+bug/1684039/+attachment/4909855/+files/xenial-open-iscsi_2.0.873+git0.3b4b4500-14ubuntu3.4.debdiff |
|
| 2017-07-05 15:24:42 |
Eric Desrochers |
open-iscsi (Ubuntu Yakkety): status |
New |
Won't Fix |
|
| 2017-07-05 15:25:23 |
Eric Desrochers |
open-iscsi (Ubuntu Artful): status |
In Progress |
Fix Committed |
|
| 2017-07-05 15:32:19 |
Eric Desrochers |
description |
When booting with iBFT, the network configuration is performed by open-iscsi as part of initramfs.local-top instead of by klibc-ipconfig. This includes populating /run/net-*.conf which is consumed among other things, by cloud-init.
Currently no attempt to determine PROTO is made, and PROTO=none is hard coded into the file which cloud-init does not recognise and crashes out.
Further to this, open-iscsi in the current version (xenial through zesty) does not correctly parse the iBFT origin into the boot protocol in "iscsistart -f" and always returns "STATIC". This is fixed upstream. |
[Impact]
When booting with iBFT, the network configuration is performed by open-iscsi as part of initramfs.local-top instead of by klibc-ipconfig. This includes populating /run/net-*.conf which is consumed among other things, by cloud-init.
Currently no attempt to determine PROTO is made, and PROTO=none is hard coded into the file which cloud-init does not recognise and crashes out.
Further to this, open-iscsi in the current version (xenial through zesty) does not correctly parse the iBFT origin into the boot protocol in "iscsistart -f" and always returns "STATIC". This is fixed upstream.
[Test Case]
[Regression Potential]
[Other Info]
* This SRU includes the following upstream/debian fixes :
# Debian:
0347300 initramfs: populate PROTO= entry in /run/net-*.conf from iBFT
# Upstream
- 08_Parse-origin-value-from-iBFT.patch --> https://github.com/open-iscsi/open-iscsi/commit/78e24f50ab754f35f4aa208ade7c9fd794d82036#diff-c53311d3f6725aa63577b7bf4b582c3d
- 09_Represent-DHCP-origin-as-an-enum-not-a-string.patch --> https://github.com/open-iscsi/open-iscsi/commit/4959a89f421fdebc521f48003a79c2161e59d192#diff-c53311d3f6725aa63577b7bf4b582c3d
- 10_iBFT-origin-is-an-enum-not-a-string.patch --> https://github.com/open-iscsi/open-iscsi/commit/3f15a2270a7efb1a6ee8ef555b01f3d8674818b9#diff-3ba89d9a64dda0ffc3664bbc27b0fa27
[Original Description]
When booting with iBFT, the network configuration is performed by open-iscsi as part of initramfs.local-top instead of by klibc-ipconfig. This includes populating /run/net-*.conf which is consumed among other things, by cloud-init.
Currently no attempt to determine PROTO is made, and PROTO=none is hard coded into the file which cloud-init does not recognise and crashes out.
Further to this, open-iscsi in the current version (xenial through zesty) does not correctly parse the iBFT origin into the boot protocol in "iscsistart -f" and always returns "STATIC". This is fixed upstream. |
|
| 2017-07-05 15:32:25 |
Eric Desrochers |
open-iscsi (Ubuntu Zesty): status |
New |
In Progress |
|
| 2017-07-05 15:32:28 |
Eric Desrochers |
open-iscsi (Ubuntu Xenial): status |
New |
In Progress |
|
| 2017-07-06 13:05:35 |
Eric Desrochers |
open-iscsi (Ubuntu Artful): assignee |
Eric Desrochers (slashd) |
Trent Lloyd (lathiat) |
|
| 2017-07-13 12:53:10 |
Eric Desrochers |
description |
[Impact]
When booting with iBFT, the network configuration is performed by open-iscsi as part of initramfs.local-top instead of by klibc-ipconfig. This includes populating /run/net-*.conf which is consumed among other things, by cloud-init.
Currently no attempt to determine PROTO is made, and PROTO=none is hard coded into the file which cloud-init does not recognise and crashes out.
Further to this, open-iscsi in the current version (xenial through zesty) does not correctly parse the iBFT origin into the boot protocol in "iscsistart -f" and always returns "STATIC". This is fixed upstream.
[Test Case]
[Regression Potential]
[Other Info]
* This SRU includes the following upstream/debian fixes :
# Debian:
0347300 initramfs: populate PROTO= entry in /run/net-*.conf from iBFT
# Upstream
- 08_Parse-origin-value-from-iBFT.patch --> https://github.com/open-iscsi/open-iscsi/commit/78e24f50ab754f35f4aa208ade7c9fd794d82036#diff-c53311d3f6725aa63577b7bf4b582c3d
- 09_Represent-DHCP-origin-as-an-enum-not-a-string.patch --> https://github.com/open-iscsi/open-iscsi/commit/4959a89f421fdebc521f48003a79c2161e59d192#diff-c53311d3f6725aa63577b7bf4b582c3d
- 10_iBFT-origin-is-an-enum-not-a-string.patch --> https://github.com/open-iscsi/open-iscsi/commit/3f15a2270a7efb1a6ee8ef555b01f3d8674818b9#diff-3ba89d9a64dda0ffc3664bbc27b0fa27
[Original Description]
When booting with iBFT, the network configuration is performed by open-iscsi as part of initramfs.local-top instead of by klibc-ipconfig. This includes populating /run/net-*.conf which is consumed among other things, by cloud-init.
Currently no attempt to determine PROTO is made, and PROTO=none is hard coded into the file which cloud-init does not recognise and crashes out.
Further to this, open-iscsi in the current version (xenial through zesty) does not correctly parse the iBFT origin into the boot protocol in "iscsistart -f" and always returns "STATIC". This is fixed upstream. |
[Impact]
When booting with iBFT, the network configuration is performed by open-iscsi as part of initramfs.local-top instead of by klibc-ipconfig. This includes populating /run/net-*.conf which is consumed among other things, by cloud-init.
Currently no attempt to determine PROTO is made, and PROTO=none is hard coded into the file which cloud-init does not recognise and crashes out.
Further to this, open-iscsi in the current version (xenial through zesty) does not correctly parse the iBFT origin into the boot protocol in "iscsistart -f" and always returns "STATIC". This is fixed upstream.
[Test Case]
[Regression Potential]
We believe the regression risk is "low" and don't envision any.
The package (including the fixes) has been intensively tested pre-SRU.
If regression is found, it'll be clearly less critical than this actual bug where cloud-init breaks because of this actual missing piece of code and It'll most likely only affect system booting with iBFT.
Additionally, the patches has been proven to work Upstream and Debian for a couple of years now.
[Other Info]
* This SRU includes the following upstream/debian fixes :
# Debian:
0347300 initramfs: populate PROTO= entry in /run/net-*.conf from iBFT
# Upstream
- 08_Parse-origin-value-from-iBFT.patch --> https://github.com/open-iscsi/open-iscsi/commit/78e24f50ab754f35f4aa208ade7c9fd794d82036#diff-c53311d3f6725aa63577b7bf4b582c3d
- 09_Represent-DHCP-origin-as-an-enum-not-a-string.patch --> https://github.com/open-iscsi/open-iscsi/commit/4959a89f421fdebc521f48003a79c2161e59d192#diff-c53311d3f6725aa63577b7bf4b582c3d
- 10_iBFT-origin-is-an-enum-not-a-string.patch --> https://github.com/open-iscsi/open-iscsi/commit/3f15a2270a7efb1a6ee8ef555b01f3d8674818b9#diff-3ba89d9a64dda0ffc3664bbc27b0fa27
[Original Description]
When booting with iBFT, the network configuration is performed by open-iscsi as part of initramfs.local-top instead of by klibc-ipconfig. This includes populating /run/net-*.conf which is consumed among other things, by cloud-init.
Currently no attempt to determine PROTO is made, and PROTO=none is hard coded into the file which cloud-init does not recognise and crashes out.
Further to this, open-iscsi in the current version (xenial through zesty) does not correctly parse the iBFT origin into the boot protocol in "iscsistart -f" and always returns "STATIC". This is fixed upstream. |
|
| 2017-07-25 08:50:57 |
Trent Lloyd |
description |
[Impact]
When booting with iBFT, the network configuration is performed by open-iscsi as part of initramfs.local-top instead of by klibc-ipconfig. This includes populating /run/net-*.conf which is consumed among other things, by cloud-init.
Currently no attempt to determine PROTO is made, and PROTO=none is hard coded into the file which cloud-init does not recognise and crashes out.
Further to this, open-iscsi in the current version (xenial through zesty) does not correctly parse the iBFT origin into the boot protocol in "iscsistart -f" and always returns "STATIC". This is fixed upstream.
[Test Case]
[Regression Potential]
We believe the regression risk is "low" and don't envision any.
The package (including the fixes) has been intensively tested pre-SRU.
If regression is found, it'll be clearly less critical than this actual bug where cloud-init breaks because of this actual missing piece of code and It'll most likely only affect system booting with iBFT.
Additionally, the patches has been proven to work Upstream and Debian for a couple of years now.
[Other Info]
* This SRU includes the following upstream/debian fixes :
# Debian:
0347300 initramfs: populate PROTO= entry in /run/net-*.conf from iBFT
# Upstream
- 08_Parse-origin-value-from-iBFT.patch --> https://github.com/open-iscsi/open-iscsi/commit/78e24f50ab754f35f4aa208ade7c9fd794d82036#diff-c53311d3f6725aa63577b7bf4b582c3d
- 09_Represent-DHCP-origin-as-an-enum-not-a-string.patch --> https://github.com/open-iscsi/open-iscsi/commit/4959a89f421fdebc521f48003a79c2161e59d192#diff-c53311d3f6725aa63577b7bf4b582c3d
- 10_iBFT-origin-is-an-enum-not-a-string.patch --> https://github.com/open-iscsi/open-iscsi/commit/3f15a2270a7efb1a6ee8ef555b01f3d8674818b9#diff-3ba89d9a64dda0ffc3664bbc27b0fa27
[Original Description]
When booting with iBFT, the network configuration is performed by open-iscsi as part of initramfs.local-top instead of by klibc-ipconfig. This includes populating /run/net-*.conf which is consumed among other things, by cloud-init.
Currently no attempt to determine PROTO is made, and PROTO=none is hard coded into the file which cloud-init does not recognise and crashes out.
Further to this, open-iscsi in the current version (xenial through zesty) does not correctly parse the iBFT origin into the boot protocol in "iscsistart -f" and always returns "STATIC". This is fixed upstream. |
[Impact]
When booting with iBFT, the network configuration is performed by open-iscsi as part of initramfs.local-top instead of by klibc-ipconfig. This includes populating /run/net-*.conf which is consumed among other things, by cloud-init.
Currently no attempt to determine PROTO is made, and PROTO=none is hard coded into the file which cloud-init does not recognise and crashes out.
Further to this, open-iscsi in the current version (xenial through zesty) does not correctly parse the iBFT origin into the boot protocol in "iscsistart -f" and always returns "STATIC". This is fixed upstream.
[Test Case]
(1) Setup MAAS 2 environment. Install 16.04 LTS images from the "Daily" Stream. Check settings and ensure Commissioning kernel is 16.04 LTS and "xenial (ga-16.04)"
(2) Enroll a libvirt virtual machine as a machine within the MAAS including a SINGLE local disk
(3) Install the 'ipxe' package on your libvirt machine
(4) Commission and test and ensure it's otherwise working
(5) You need to build a new open-iscsi package for xenial with the fix, and then rebuild an initrd for 4.4.0-87-generic with the fix integrated. An easy way to do that is to deploy the machine, install the updated (fixed) package and then copy the initrd from /boot/initrd.img-4.4.0-87-generic to the MAAS server. But you could also build it on any other xenial machine with that kernel installed.
(6) Edit the virtual machine config using virt-manager and under the "Boot Options" enable direct kernel boot, set kernel path to /usr/lib/ipxe/ipxe.lkrn and the kernel args to (all one line):
ifconf -c dhcp && sanhook --drive 0x81 iscsi:100.64.0.253::3260:1:iqn.2004-05.com.ubuntu:maas:ephemeral-ubuntu-amd64-ga-16.04-xenial-daily ; autoboot
Change 100.64.0.253 to the IP of your MAAS instance on the network that it uses to PXE boot.
(7) Try to commission the machine again, you should see it fail if you watch the console (it will also show failed in MAAS) and you'll briefly see a message about PROTO=none
(8) Update the initrd on the MAAS server:
cd /var/lib/maas/boot-resources/current/ubuntu/amd64/ga-16.04/xenial/daily/
mv boot-initrd boot-initrd.orig
cp (PATHMAYBEDIFFERENT)/boot/initrd.img-4.4.0-87-generic boot-initrd
(9) Try to commission the machine again, it should now succeed with the patched initrd. A deployment will also work but a commission is sufficient enough to test.
Notes:
- MAAS may do an image sync and overwrite your updated initrd. So watch out for that. boot-resources/current is also a symlink so you may need to cd out and back in
Advantage of using MAAS to do this is that it also tests that iSCSI boot is otherwise working and not broken by this change, as the commission and deploy etc use iSCSI root. There is also a test for this in debian/tests (tgt-boot-test)
[Regression Potential]
We believe the regression risk is "low" and don't envision any.
The package (including the fixes) has been intensively tested pre-SRU.
If regression is found, it'll be clearly less critical than this actual bug where cloud-init breaks because of this actual missing piece of code and It'll most likely only affect system booting with iBFT.
Additionally, the patches has been proven to work Upstream and Debian for a couple of years now.
[Other Info]
* This SRU includes the following upstream/debian fixes :
# Debian:
0347300 initramfs: populate PROTO= entry in /run/net-*.conf from iBFT
# Upstream
- 08_Parse-origin-value-from-iBFT.patch --> https://github.com/open-iscsi/open-iscsi/commit/78e24f50ab754f35f4aa208ade7c9fd794d82036#diff-c53311d3f6725aa63577b7bf4b582c3d
- 09_Represent-DHCP-origin-as-an-enum-not-a-string.patch --> https://github.com/open-iscsi/open-iscsi/commit/4959a89f421fdebc521f48003a79c2161e59d192#diff-c53311d3f6725aa63577b7bf4b582c3d
- 10_iBFT-origin-is-an-enum-not-a-string.patch --> https://github.com/open-iscsi/open-iscsi/commit/3f15a2270a7efb1a6ee8ef555b01f3d8674818b9#diff-3ba89d9a64dda0ffc3664bbc27b0fa27
[Original Description]
When booting with iBFT, the network configuration is performed by open-iscsi as part of initramfs.local-top instead of by klibc-ipconfig. This includes populating /run/net-*.conf which is consumed among other things, by cloud-init.
Currently no attempt to determine PROTO is made, and PROTO=none is hard coded into the file which cloud-init does not recognise and crashes out.
Further to this, open-iscsi in the current version (xenial through zesty) does not correctly parse the iBFT origin into the boot protocol in "iscsistart -f" and always returns "STATIC". This is fixed upstream. |
|
| 2017-07-25 08:54:48 |
Trent Lloyd |
description |
[Impact]
When booting with iBFT, the network configuration is performed by open-iscsi as part of initramfs.local-top instead of by klibc-ipconfig. This includes populating /run/net-*.conf which is consumed among other things, by cloud-init.
Currently no attempt to determine PROTO is made, and PROTO=none is hard coded into the file which cloud-init does not recognise and crashes out.
Further to this, open-iscsi in the current version (xenial through zesty) does not correctly parse the iBFT origin into the boot protocol in "iscsistart -f" and always returns "STATIC". This is fixed upstream.
[Test Case]
(1) Setup MAAS 2 environment. Install 16.04 LTS images from the "Daily" Stream. Check settings and ensure Commissioning kernel is 16.04 LTS and "xenial (ga-16.04)"
(2) Enroll a libvirt virtual machine as a machine within the MAAS including a SINGLE local disk
(3) Install the 'ipxe' package on your libvirt machine
(4) Commission and test and ensure it's otherwise working
(5) You need to build a new open-iscsi package for xenial with the fix, and then rebuild an initrd for 4.4.0-87-generic with the fix integrated. An easy way to do that is to deploy the machine, install the updated (fixed) package and then copy the initrd from /boot/initrd.img-4.4.0-87-generic to the MAAS server. But you could also build it on any other xenial machine with that kernel installed.
(6) Edit the virtual machine config using virt-manager and under the "Boot Options" enable direct kernel boot, set kernel path to /usr/lib/ipxe/ipxe.lkrn and the kernel args to (all one line):
ifconf -c dhcp && sanhook --drive 0x81 iscsi:100.64.0.253::3260:1:iqn.2004-05.com.ubuntu:maas:ephemeral-ubuntu-amd64-ga-16.04-xenial-daily ; autoboot
Change 100.64.0.253 to the IP of your MAAS instance on the network that it uses to PXE boot.
(7) Try to commission the machine again, you should see it fail if you watch the console (it will also show failed in MAAS) and you'll briefly see a message about PROTO=none
(8) Update the initrd on the MAAS server:
cd /var/lib/maas/boot-resources/current/ubuntu/amd64/ga-16.04/xenial/daily/
mv boot-initrd boot-initrd.orig
cp (PATHMAYBEDIFFERENT)/boot/initrd.img-4.4.0-87-generic boot-initrd
(9) Try to commission the machine again, it should now succeed with the patched initrd. A deployment will also work but a commission is sufficient enough to test.
Notes:
- MAAS may do an image sync and overwrite your updated initrd. So watch out for that. boot-resources/current is also a symlink so you may need to cd out and back in
Advantage of using MAAS to do this is that it also tests that iSCSI boot is otherwise working and not broken by this change, as the commission and deploy etc use iSCSI root. There is also a test for this in debian/tests (tgt-boot-test)
[Regression Potential]
We believe the regression risk is "low" and don't envision any.
The package (including the fixes) has been intensively tested pre-SRU.
If regression is found, it'll be clearly less critical than this actual bug where cloud-init breaks because of this actual missing piece of code and It'll most likely only affect system booting with iBFT.
Additionally, the patches has been proven to work Upstream and Debian for a couple of years now.
[Other Info]
* This SRU includes the following upstream/debian fixes :
# Debian:
0347300 initramfs: populate PROTO= entry in /run/net-*.conf from iBFT
# Upstream
- 08_Parse-origin-value-from-iBFT.patch --> https://github.com/open-iscsi/open-iscsi/commit/78e24f50ab754f35f4aa208ade7c9fd794d82036#diff-c53311d3f6725aa63577b7bf4b582c3d
- 09_Represent-DHCP-origin-as-an-enum-not-a-string.patch --> https://github.com/open-iscsi/open-iscsi/commit/4959a89f421fdebc521f48003a79c2161e59d192#diff-c53311d3f6725aa63577b7bf4b582c3d
- 10_iBFT-origin-is-an-enum-not-a-string.patch --> https://github.com/open-iscsi/open-iscsi/commit/3f15a2270a7efb1a6ee8ef555b01f3d8674818b9#diff-3ba89d9a64dda0ffc3664bbc27b0fa27
[Original Description]
When booting with iBFT, the network configuration is performed by open-iscsi as part of initramfs.local-top instead of by klibc-ipconfig. This includes populating /run/net-*.conf which is consumed among other things, by cloud-init.
Currently no attempt to determine PROTO is made, and PROTO=none is hard coded into the file which cloud-init does not recognise and crashes out.
Further to this, open-iscsi in the current version (xenial through zesty) does not correctly parse the iBFT origin into the boot protocol in "iscsistart -f" and always returns "STATIC". This is fixed upstream. |
[Impact]
When booting with iBFT, the network configuration is performed by open-iscsi as part of initramfs.local-top instead of by klibc-ipconfig. This includes populating /run/net-*.conf which is consumed among other things, by cloud-init.
Currently no attempt to determine PROTO is made, and PROTO=none is hard coded into the file which cloud-init does not recognise and crashes out.
Further to this, open-iscsi in the current version (xenial through zesty) does not correctly parse the iBFT origin into the boot protocol in "iscsistart -f" and always returns "STATIC". This is fixed upstream.
[Test Case]
(1) Setup MAAS 2 environment. Install 16.04 LTS images from the "Daily" Stream. Check settings and ensure Commissioning kernel is 16.04 LTS and "xenial (ga-16.04)"
(2) Enroll a libvirt virtual machine as a machine within the MAAS including a SINGLE local disk
(3) Install the 'ipxe' package on your libvirt machine
(4) Commission and test and ensure it's otherwise working
(5) Update MAAS settings and add iscsi_auto to the "Global Kernel Parameters"
(5) You need to build a new open-iscsi package for xenial with the fix, and then rebuild an initrd for 4.4.0-87-generic with the fix integrated. An easy way to do that is to deploy the machine, install the updated (fixed) package and then copy the initrd from /boot/initrd.img-4.4.0-87-generic to the MAAS server. But you could also build it on any other xenial machine with that kernel installed.
(6) Edit the virtual machine config using virt-manager and under the "Boot Options" enable direct kernel boot, set kernel path to /usr/lib/ipxe/ipxe.lkrn and the kernel args to (all one line):
ifconf -c dhcp && sanhook --drive 0x81 iscsi:100.64.0.253::3260:1:iqn.2004-05.com.ubuntu:maas:ephemeral-ubuntu-amd64-ga-16.04-xenial-daily ; autoboot
Change 100.64.0.253 to the IP of your MAAS instance on the network that it uses to PXE boot.
(7) Try to commission the machine again, you should see it fail if you watch the console (it will also show failed in MAAS) and you'll briefly see a message about PROTO=none
(8) Update the initrd on the MAAS server:
cd /var/lib/maas/boot-resources/current/ubuntu/amd64/ga-16.04/xenial/daily/
mv boot-initrd boot-initrd.orig
cp (PATHMAYBEDIFFERENT)/boot/initrd.img-4.4.0-87-generic boot-initrd
(9) Try to commission the machine again, it should now succeed with the patched initrd. A deployment will also work but a commission is sufficient enough to test.
Notes:
- MAAS may do an image sync and overwrite your updated initrd. So watch out for that. boot-resources/current is also a symlink so you may need to cd out and back in
Advantage of using MAAS to do this is that it also tests that iSCSI boot is otherwise working and not broken by this change, as the commission and deploy etc use iSCSI root. There is also a test for this in debian/tests (tgt-boot-test)
[Regression Potential]
We believe the regression risk is "low" and don't envision any.
The package (including the fixes) has been intensively tested pre-SRU.
If regression is found, it'll be clearly less critical than this actual bug where cloud-init breaks because of this actual missing piece of code and It'll most likely only affect system booting with iBFT.
Additionally, the patches has been proven to work Upstream and Debian for a couple of years now.
[Other Info]
* This SRU includes the following upstream/debian fixes :
# Debian:
0347300 initramfs: populate PROTO= entry in /run/net-*.conf from iBFT
# Upstream
- 08_Parse-origin-value-from-iBFT.patch --> https://github.com/open-iscsi/open-iscsi/commit/78e24f50ab754f35f4aa208ade7c9fd794d82036#diff-c53311d3f6725aa63577b7bf4b582c3d
- 09_Represent-DHCP-origin-as-an-enum-not-a-string.patch --> https://github.com/open-iscsi/open-iscsi/commit/4959a89f421fdebc521f48003a79c2161e59d192#diff-c53311d3f6725aa63577b7bf4b582c3d
- 10_iBFT-origin-is-an-enum-not-a-string.patch --> https://github.com/open-iscsi/open-iscsi/commit/3f15a2270a7efb1a6ee8ef555b01f3d8674818b9#diff-3ba89d9a64dda0ffc3664bbc27b0fa27
[Original Description]
When booting with iBFT, the network configuration is performed by open-iscsi as part of initramfs.local-top instead of by klibc-ipconfig. This includes populating /run/net-*.conf which is consumed among other things, by cloud-init.
Currently no attempt to determine PROTO is made, and PROTO=none is hard coded into the file which cloud-init does not recognise and crashes out.
Further to this, open-iscsi in the current version (xenial through zesty) does not correctly parse the iBFT origin into the boot protocol in "iscsistart -f" and always returns "STATIC". This is fixed upstream. |
|
| 2017-07-25 08:55:13 |
Trent Lloyd |
description |
[Impact]
When booting with iBFT, the network configuration is performed by open-iscsi as part of initramfs.local-top instead of by klibc-ipconfig. This includes populating /run/net-*.conf which is consumed among other things, by cloud-init.
Currently no attempt to determine PROTO is made, and PROTO=none is hard coded into the file which cloud-init does not recognise and crashes out.
Further to this, open-iscsi in the current version (xenial through zesty) does not correctly parse the iBFT origin into the boot protocol in "iscsistart -f" and always returns "STATIC". This is fixed upstream.
[Test Case]
(1) Setup MAAS 2 environment. Install 16.04 LTS images from the "Daily" Stream. Check settings and ensure Commissioning kernel is 16.04 LTS and "xenial (ga-16.04)"
(2) Enroll a libvirt virtual machine as a machine within the MAAS including a SINGLE local disk
(3) Install the 'ipxe' package on your libvirt machine
(4) Commission and test and ensure it's otherwise working
(5) Update MAAS settings and add iscsi_auto to the "Global Kernel Parameters"
(5) You need to build a new open-iscsi package for xenial with the fix, and then rebuild an initrd for 4.4.0-87-generic with the fix integrated. An easy way to do that is to deploy the machine, install the updated (fixed) package and then copy the initrd from /boot/initrd.img-4.4.0-87-generic to the MAAS server. But you could also build it on any other xenial machine with that kernel installed.
(6) Edit the virtual machine config using virt-manager and under the "Boot Options" enable direct kernel boot, set kernel path to /usr/lib/ipxe/ipxe.lkrn and the kernel args to (all one line):
ifconf -c dhcp && sanhook --drive 0x81 iscsi:100.64.0.253::3260:1:iqn.2004-05.com.ubuntu:maas:ephemeral-ubuntu-amd64-ga-16.04-xenial-daily ; autoboot
Change 100.64.0.253 to the IP of your MAAS instance on the network that it uses to PXE boot.
(7) Try to commission the machine again, you should see it fail if you watch the console (it will also show failed in MAAS) and you'll briefly see a message about PROTO=none
(8) Update the initrd on the MAAS server:
cd /var/lib/maas/boot-resources/current/ubuntu/amd64/ga-16.04/xenial/daily/
mv boot-initrd boot-initrd.orig
cp (PATHMAYBEDIFFERENT)/boot/initrd.img-4.4.0-87-generic boot-initrd
(9) Try to commission the machine again, it should now succeed with the patched initrd. A deployment will also work but a commission is sufficient enough to test.
Notes:
- MAAS may do an image sync and overwrite your updated initrd. So watch out for that. boot-resources/current is also a symlink so you may need to cd out and back in
Advantage of using MAAS to do this is that it also tests that iSCSI boot is otherwise working and not broken by this change, as the commission and deploy etc use iSCSI root. There is also a test for this in debian/tests (tgt-boot-test)
[Regression Potential]
We believe the regression risk is "low" and don't envision any.
The package (including the fixes) has been intensively tested pre-SRU.
If regression is found, it'll be clearly less critical than this actual bug where cloud-init breaks because of this actual missing piece of code and It'll most likely only affect system booting with iBFT.
Additionally, the patches has been proven to work Upstream and Debian for a couple of years now.
[Other Info]
* This SRU includes the following upstream/debian fixes :
# Debian:
0347300 initramfs: populate PROTO= entry in /run/net-*.conf from iBFT
# Upstream
- 08_Parse-origin-value-from-iBFT.patch --> https://github.com/open-iscsi/open-iscsi/commit/78e24f50ab754f35f4aa208ade7c9fd794d82036#diff-c53311d3f6725aa63577b7bf4b582c3d
- 09_Represent-DHCP-origin-as-an-enum-not-a-string.patch --> https://github.com/open-iscsi/open-iscsi/commit/4959a89f421fdebc521f48003a79c2161e59d192#diff-c53311d3f6725aa63577b7bf4b582c3d
- 10_iBFT-origin-is-an-enum-not-a-string.patch --> https://github.com/open-iscsi/open-iscsi/commit/3f15a2270a7efb1a6ee8ef555b01f3d8674818b9#diff-3ba89d9a64dda0ffc3664bbc27b0fa27
[Original Description]
When booting with iBFT, the network configuration is performed by open-iscsi as part of initramfs.local-top instead of by klibc-ipconfig. This includes populating /run/net-*.conf which is consumed among other things, by cloud-init.
Currently no attempt to determine PROTO is made, and PROTO=none is hard coded into the file which cloud-init does not recognise and crashes out.
Further to this, open-iscsi in the current version (xenial through zesty) does not correctly parse the iBFT origin into the boot protocol in "iscsistart -f" and always returns "STATIC". This is fixed upstream. |
[Impact]
When booting with iBFT, the network configuration is performed by open-iscsi as part of initramfs.local-top instead of by klibc-ipconfig. This includes populating /run/net-*.conf which is consumed among other things, by cloud-init.
Currently no attempt to determine PROTO is made, and PROTO=none is hard coded into the file which cloud-init does not recognise and crashes out.
Further to this, open-iscsi in the current version (xenial through zesty) does not correctly parse the iBFT origin into the boot protocol in "iscsistart -f" and always returns "STATIC". This is fixed upstream.
[Test Case]
(1) Setup MAAS 2 environment. Install 16.04 LTS images from the "Daily" Stream. Check settings and ensure Commissioning kernel is 16.04 LTS and "xenial (ga-16.04)"
(2) Enroll a libvirt virtual machine as a machine within the MAAS including a SINGLE local disk
(3) Install the 'ipxe' package on your libvirt machine
(4) Commission and test and ensure it's otherwise working
(5) Update MAAS settings and add iscsi_auto to the "Global Kernel Parameters"
(6) You need to build a new open-iscsi package for xenial with the fix, and then rebuild an initrd for 4.4.0-87-generic with the fix integrated. An easy way to do that is to deploy the machine, install the updated (fixed) package and then copy the initrd from /boot/initrd.img-4.4.0-87-generic to the MAAS server. But you could also build it on any other xenial machine with that kernel installed.
(7) Edit the virtual machine config using virt-manager and under the "Boot Options" enable direct kernel boot, set kernel path to /usr/lib/ipxe/ipxe.lkrn and the kernel args to (all one line):
ifconf -c dhcp && sanhook --drive 0x81 iscsi:100.64.0.253::3260:1:iqn.2004-05.com.ubuntu:maas:ephemeral-ubuntu-amd64-ga-16.04-xenial-daily ; autoboot
Change 100.64.0.253 to the IP of your MAAS instance on the network that it uses to PXE boot.
(8) Try to commission the machine again, you should see it fail if you watch the console (it will also show failed in MAAS) and you'll briefly see a message about PROTO=none
(9) Update the initrd on the MAAS server:
cd /var/lib/maas/boot-resources/current/ubuntu/amd64/ga-16.04/xenial/daily/
mv boot-initrd boot-initrd.orig
cp (PATHMAYBEDIFFERENT)/boot/initrd.img-4.4.0-87-generic boot-initrd
(10) Try to commission the machine again, it should now succeed with the patched initrd. A deployment will also work but a commission is sufficient enough to test.
Notes:
- MAAS may do an image sync and overwrite your updated initrd. So watch out for that. boot-resources/current is also a symlink so you may need to cd out and back in
- Advantage of using MAAS to do this is that it also tests that iSCSI boot is otherwise working and not broken by this change, as the commission and deploy etc use iSCSI root. There is also a test for this in debian/tests (tgt-boot-test)
[Regression Potential]
We believe the regression risk is "low" and don't envision any.
The package (including the fixes) has been intensively tested pre-SRU.
If regression is found, it'll be clearly less critical than this actual bug where cloud-init breaks because of this actual missing piece of code and It'll most likely only affect system booting with iBFT.
Additionally, the patches has been proven to work Upstream and Debian for a couple of years now.
[Other Info]
* This SRU includes the following upstream/debian fixes :
# Debian:
0347300 initramfs: populate PROTO= entry in /run/net-*.conf from iBFT
# Upstream
- 08_Parse-origin-value-from-iBFT.patch --> https://github.com/open-iscsi/open-iscsi/commit/78e24f50ab754f35f4aa208ade7c9fd794d82036#diff-c53311d3f6725aa63577b7bf4b582c3d
- 09_Represent-DHCP-origin-as-an-enum-not-a-string.patch --> https://github.com/open-iscsi/open-iscsi/commit/4959a89f421fdebc521f48003a79c2161e59d192#diff-c53311d3f6725aa63577b7bf4b582c3d
- 10_iBFT-origin-is-an-enum-not-a-string.patch --> https://github.com/open-iscsi/open-iscsi/commit/3f15a2270a7efb1a6ee8ef555b01f3d8674818b9#diff-3ba89d9a64dda0ffc3664bbc27b0fa27
[Original Description]
When booting with iBFT, the network configuration is performed by open-iscsi as part of initramfs.local-top instead of by klibc-ipconfig. This includes populating /run/net-*.conf which is consumed among other things, by cloud-init.
Currently no attempt to determine PROTO is made, and PROTO=none is hard coded into the file which cloud-init does not recognise and crashes out.
Further to this, open-iscsi in the current version (xenial through zesty) does not correctly parse the iBFT origin into the boot protocol in "iscsistart -f" and always returns "STATIC". This is fixed upstream. |
|
| 2017-07-25 13:12:37 |
Eric Desrochers |
bug |
|
|
added subscriber SRU Verification |
| 2017-07-25 13:12:52 |
Eric Desrochers |
tags |
patch sts-sru-needed |
sts-sponsor-done sts-sru-needed |
|
| 2017-07-26 15:13:26 |
Łukasz Zemczak |
open-iscsi (Ubuntu Xenial): status |
In Progress |
Fix Committed |
|
| 2017-07-26 15:13:28 |
Łukasz Zemczak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2017-07-26 15:13:31 |
Łukasz Zemczak |
tags |
sts-sponsor-done sts-sru-needed |
sts-sponsor-done sts-sru-needed verification-needed verification-needed-xenial |
|
| 2017-07-28 13:15:54 |
Eric Desrochers |
description |
[Impact]
When booting with iBFT, the network configuration is performed by open-iscsi as part of initramfs.local-top instead of by klibc-ipconfig. This includes populating /run/net-*.conf which is consumed among other things, by cloud-init.
Currently no attempt to determine PROTO is made, and PROTO=none is hard coded into the file which cloud-init does not recognise and crashes out.
Further to this, open-iscsi in the current version (xenial through zesty) does not correctly parse the iBFT origin into the boot protocol in "iscsistart -f" and always returns "STATIC". This is fixed upstream.
[Test Case]
(1) Setup MAAS 2 environment. Install 16.04 LTS images from the "Daily" Stream. Check settings and ensure Commissioning kernel is 16.04 LTS and "xenial (ga-16.04)"
(2) Enroll a libvirt virtual machine as a machine within the MAAS including a SINGLE local disk
(3) Install the 'ipxe' package on your libvirt machine
(4) Commission and test and ensure it's otherwise working
(5) Update MAAS settings and add iscsi_auto to the "Global Kernel Parameters"
(6) You need to build a new open-iscsi package for xenial with the fix, and then rebuild an initrd for 4.4.0-87-generic with the fix integrated. An easy way to do that is to deploy the machine, install the updated (fixed) package and then copy the initrd from /boot/initrd.img-4.4.0-87-generic to the MAAS server. But you could also build it on any other xenial machine with that kernel installed.
(7) Edit the virtual machine config using virt-manager and under the "Boot Options" enable direct kernel boot, set kernel path to /usr/lib/ipxe/ipxe.lkrn and the kernel args to (all one line):
ifconf -c dhcp && sanhook --drive 0x81 iscsi:100.64.0.253::3260:1:iqn.2004-05.com.ubuntu:maas:ephemeral-ubuntu-amd64-ga-16.04-xenial-daily ; autoboot
Change 100.64.0.253 to the IP of your MAAS instance on the network that it uses to PXE boot.
(8) Try to commission the machine again, you should see it fail if you watch the console (it will also show failed in MAAS) and you'll briefly see a message about PROTO=none
(9) Update the initrd on the MAAS server:
cd /var/lib/maas/boot-resources/current/ubuntu/amd64/ga-16.04/xenial/daily/
mv boot-initrd boot-initrd.orig
cp (PATHMAYBEDIFFERENT)/boot/initrd.img-4.4.0-87-generic boot-initrd
(10) Try to commission the machine again, it should now succeed with the patched initrd. A deployment will also work but a commission is sufficient enough to test.
Notes:
- MAAS may do an image sync and overwrite your updated initrd. So watch out for that. boot-resources/current is also a symlink so you may need to cd out and back in
- Advantage of using MAAS to do this is that it also tests that iSCSI boot is otherwise working and not broken by this change, as the commission and deploy etc use iSCSI root. There is also a test for this in debian/tests (tgt-boot-test)
[Regression Potential]
We believe the regression risk is "low" and don't envision any.
The package (including the fixes) has been intensively tested pre-SRU.
If regression is found, it'll be clearly less critical than this actual bug where cloud-init breaks because of this actual missing piece of code and It'll most likely only affect system booting with iBFT.
Additionally, the patches has been proven to work Upstream and Debian for a couple of years now.
[Other Info]
* This SRU includes the following upstream/debian fixes :
# Debian:
0347300 initramfs: populate PROTO= entry in /run/net-*.conf from iBFT
# Upstream
- 08_Parse-origin-value-from-iBFT.patch --> https://github.com/open-iscsi/open-iscsi/commit/78e24f50ab754f35f4aa208ade7c9fd794d82036#diff-c53311d3f6725aa63577b7bf4b582c3d
- 09_Represent-DHCP-origin-as-an-enum-not-a-string.patch --> https://github.com/open-iscsi/open-iscsi/commit/4959a89f421fdebc521f48003a79c2161e59d192#diff-c53311d3f6725aa63577b7bf4b582c3d
- 10_iBFT-origin-is-an-enum-not-a-string.patch --> https://github.com/open-iscsi/open-iscsi/commit/3f15a2270a7efb1a6ee8ef555b01f3d8674818b9#diff-3ba89d9a64dda0ffc3664bbc27b0fa27
[Original Description]
When booting with iBFT, the network configuration is performed by open-iscsi as part of initramfs.local-top instead of by klibc-ipconfig. This includes populating /run/net-*.conf which is consumed among other things, by cloud-init.
Currently no attempt to determine PROTO is made, and PROTO=none is hard coded into the file which cloud-init does not recognise and crashes out.
Further to this, open-iscsi in the current version (xenial through zesty) does not correctly parse the iBFT origin into the boot protocol in "iscsistart -f" and always returns "STATIC". This is fixed upstream. |
[Impact]
When booting with iBFT, the network configuration is performed by open-iscsi as part of initramfs.local-top instead of by klibc-ipconfig. This includes populating /run/net-*.conf which is consumed among other things, by cloud-init.
Currently no attempt to determine PROTO is made, and PROTO=none is hard coded into the file which cloud-init does not recognise and crashes out.
Further to this, open-iscsi in the current version (xenial through zesty) does not correctly parse the iBFT origin into the boot protocol in "iscsistart -f" and always returns "STATIC". This is fixed upstream.
[Test Case]
(1) Setup MAAS 2 environment. Install 16.04 LTS images from the "Daily" Stream. Check settings and ensure Commissioning kernel is 16.04 LTS and "xenial (ga-16.04)"
(2) Enroll a libvirt virtual machine as a machine within the MAAS including a SINGLE local disk
(3) Install the 'ipxe' package on your libvirt machine
(4) Commission and test and ensure it's otherwise working
(5) Update MAAS settings and add iscsi_auto to the "Global Kernel Parameters"
(6) You need to build a new open-iscsi package for xenial with the fix, and then rebuild an initrd for 4.4.0-87-generic with the fix integrated. An easy way to do that is to deploy the machine, install the updated (fixed) package and then copy the initrd from /boot/initrd.img-4.4.0-87-generic to the MAAS server. But you could also build it on any other xenial machine with that kernel installed.
(7) Edit the virtual machine config using virt-manager and under the "Boot Options" enable direct kernel boot, set kernel path to /usr/lib/ipxe/ipxe.lkrn and the kernel args to (all one line):
ifconf -c dhcp && sanhook --drive 0x81 iscsi:100.64.0.253::3260:1:iqn.2004-05.com.ubuntu:maas:ephemeral-ubuntu-amd64-ga-16.04-xenial-daily ; autoboot
Change 100.64.0.253 to the IP of your MAAS instance on the network that it uses to PXE boot.
(8) Try to commission the machine again, you should see it fail if you watch the console (it will also show failed in MAAS) and you'll briefly see a message about PROTO=none
(9) Update the initrd on the MAAS server:
cd /var/lib/maas/boot-resources/current/ubuntu/amd64/ga-16.04/xenial/daily/
mv boot-initrd boot-initrd.orig
cp (PATHMAYBEDIFFERENT)/boot/initrd.img-4.4.0-87-generic boot-initrd
(10) Try to commission the machine again, it should now succeed with the patched initrd. A deployment will also work but a commission is sufficient enough to test.
Notes:
- MAAS may do an image sync and overwrite your updated initrd. So watch out for that. boot-resources/current is also a symlink so you may need to cd out and back in
- Advantage of using MAAS to do this is that it also tests that iSCSI boot is otherwise working and not broken by this change, as the commission and deploy etc use iSCSI root. There is also a test for this in debian/tests (tgt-boot-test)
[Regression Potential]
We believe the regression risk is "low" and don't envision any.
The package (including the fixes) has been intensively tested pre-SRU.
If regression is found, it'll be clearly less critical than this actual bug where cloud-init breaks because of this actual missing piece of code and It'll most likely only affect system booting with iBFT.
Additionally, the patches has been proven to work Upstream and Debian for a couple of years now.
* autopkgtest failure
==
XENIAL
==
* Regression in autopkgtest for open-iscsi (i386): test log
This autopkgtest started to fail more than a year ago, more precisely on "2016-03-30"[1] with open-iscsi version : "2.0.873+git0.3b4b4500-14ubuntu2"
Meaning that this was already there prior to this current SRU.
[1] - http://autopkgtest.ubuntu.com/packages/o/open-iscsi/xenial/i386
2.0.873+git0.3b4b4500-14ubuntu2 open-iscsi/2.0.873+git0.3b4b4500-14ubuntu2 2016-03-30 03:46:43 UTC 0h 27m 12s fail log artifacts
* Regression in autopkgtest for open-iscsi (amd64): test log
This autopkgtest started to fail more than a year ago, more precisely on "2016-04-13"[2] with open-iscsi version : "2.0.873+git0.3b4b4500-14ubuntu2"
Meaning that this was already there prior to this current SRU.
[2] - http://autopkgtest.ubuntu.com/packages/o/open-iscsi/xenial/amd64
2.0.873+git0.3b4b4500-14ubuntu2 open-iscsi/2.0.873+git0.3b4b4500-14ubuntu2 2016-04-13 07:13:11 UTC 0h 16m 17s fail log artifacts
==
[Other Info]
* This SRU includes the following upstream/debian fixes :
# Debian:
0347300 initramfs: populate PROTO= entry in /run/net-*.conf from iBFT
# Upstream
- 08_Parse-origin-value-from-iBFT.patch --> https://github.com/open-iscsi/open-iscsi/commit/78e24f50ab754f35f4aa208ade7c9fd794d82036#diff-c53311d3f6725aa63577b7bf4b582c3d
- 09_Represent-DHCP-origin-as-an-enum-not-a-string.patch --> https://github.com/open-iscsi/open-iscsi/commit/4959a89f421fdebc521f48003a79c2161e59d192#diff-c53311d3f6725aa63577b7bf4b582c3d
- 10_iBFT-origin-is-an-enum-not-a-string.patch --> https://github.com/open-iscsi/open-iscsi/commit/3f15a2270a7efb1a6ee8ef555b01f3d8674818b9#diff-3ba89d9a64dda0ffc3664bbc27b0fa27
[Original Description]
When booting with iBFT, the network configuration is performed by open-iscsi as part of initramfs.local-top instead of by klibc-ipconfig. This includes populating /run/net-*.conf which is consumed among other things, by cloud-init.
Currently no attempt to determine PROTO is made, and PROTO=none is hard coded into the file which cloud-init does not recognise and crashes out.
Further to this, open-iscsi in the current version (xenial through zesty) does not correctly parse the iBFT origin into the boot protocol in "iscsistart -f" and always returns "STATIC". This is fixed upstream. |
|
| 2017-08-01 08:22:40 |
Trent Lloyd |
tags |
sts-sponsor-done sts-sru-needed verification-needed verification-needed-xenial |
sts-sponsor-done sts-sru-needed verification-done verification-done-xenial |
|
| 2017-08-01 09:57:34 |
Adam Conrad |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2017-08-01 09:58:20 |
Launchpad Janitor |
open-iscsi (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2017-08-01 11:38:57 |
Eric Desrochers |
tags |
sts-sponsor-done sts-sru-needed verification-done verification-done-xenial |
sts-sponsor-done sts-sru-needed verification-done verification-done-xenial verification-done-zesty |
|
| 2017-08-01 12:56:37 |
Eric Desrochers |
open-iscsi (Ubuntu Zesty): status |
In Progress |
Fix Committed |
|
| 2017-08-07 15:25:13 |
Eric Desrochers |
bug |
|
|
added subscriber Nish Aravamudan |
| 2017-08-07 15:48:48 |
Launchpad Janitor |
open-iscsi (Ubuntu Zesty): status |
Fix Committed |
Fix Released |
|
| 2017-08-07 16:26:38 |
Eric Desrochers |
tags |
sts-sponsor-done sts-sru-needed verification-done verification-done-xenial verification-done-zesty |
sts sts-sponsor-done verification-done verification-done-xenial verification-done-zesty |
|
| 2017-08-09 01:06:51 |
Launchpad Janitor |
open-iscsi (Ubuntu Artful): status |
Fix Committed |
Fix Released |
|
| 2020-01-13 22:06:01 |
Ebbex |
bug |
|
|
added subscriber Ebbex |
