[Bug 1684039] Re: iBFT network configuration does not correctly populate PROTO=dhcp in /run/net-*.conf which breaks cloud-init
Trent Lloyd
trent.lloyd at canonical.com
Tue Jul 25 08:51:02 UTC 2017
Test case updated
** Description changed:
[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.
** Description changed:
[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
+ 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
+ (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
+ - 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.
** Description changed:
[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,
+ (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.
- (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):
+ (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.
- (7) Try to commission the machine again, you should see it fail if you
+ (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
- (8) Update the initrd on the MAAS server:
+ (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
- (9) Try to commission the machine again, it should now succeed with the
+ (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)
+ - 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.
--
You received this bug notification because you are a member of Ubuntu
Sponsors Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1684039
Title:
iBFT network configuration does not correctly populate PROTO=dhcp in
/run/net-*.conf which breaks cloud-init
Status in open-iscsi package in Ubuntu:
Fix Committed
Status in open-iscsi source package in Xenial:
In Progress
Status in open-iscsi source package in Yakkety:
Won't Fix
Status in open-iscsi source package in Zesty:
In Progress
Status in open-iscsi source package in Artful:
Fix Committed
Status in open-iscsi package in Debian:
Fix Released
Bug 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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/open-iscsi/+bug/1684039/+subscriptions
More information about the Ubuntu-sponsors
mailing list