[Yahoo-eng-team] [Bug 1986551] Re: Current kinetic ISO images not installable on s390x
I can confirm that this issue is fixed with the latest 'pending' ISO from today (Sept 1st): https://cdimage.ubuntu.com/ubuntu-server/daily-live/pending/kinetic-live-server-s390x.iso Many thx! I tried that on two systems and I was able to reach subiquity - so, complete the initial basic network configuration. I was able to complete the entire installation on one of the systems, but faced another (independent) problem on the 2nd one - will open a separate bug for that (LP#1988407). But this bug can be closed now as Fix Released. ** Changed in: ubuntu-z-systems Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1986551 Title: Current kinetic ISO images not installable on s390x Status in cloud-init: Fix Released Status in subiquity: Invalid Status in Ubuntu on IBM z Systems: Fix Released Bug description: While wanting to install an kinetic/22.10 system on s390x for testing new and updated packages I found that the current daily ISO image for s390x is not installable - not on LPAR nor on z/VM - not interactively using subiquity, not non-interactively using autoinstall. I had the image from August 2nd and the installation ended at the console with these messages (please ignore the weird special characters): ... Ý Ý0;32m OK Ý0m¨ Started Ý0;1;39mTime & Date Service Ý0m. connecting... - \ | waiting for cloud-init... - It is possible to connect to the installer over the network, which might allow the use of a more capable terminal and can offer more languages than can be rendered in the Linux console. Unfortunately this system seems to have no global IP addresses at this time. Starting Ý0;1;39mTime & Date Service Ý0m... Ý Ý0;32m OK Ý0m¨ Started Ý0;1;39mTime & Date Service Ý0m. Ý Ý0;32m OK Ý0m¨ Finished Ý0;1;39mWait until snapd is fully seeded Ý0m. Starting Ý0;1;39mApply the settings specified in cloud-config Ý0m... Ý Ý0;32m OK Ý0m¨ Started Ý0;1;39mSubiquity, the installer for Ubuntu Server hvc0 Ý0m. Ý Ý0;32m OK Ý0m¨ Started Ý0;1;39mSubiquity, the ins er for Ubuntu Server t tysclp0 Ý0m. Ý Ý0;32m OK Ý0m¨ Reached target Ý0;1;39mLogin Prompts Ý0m. Stopping Ý0;1;39mOpenBSD Secure Shell server Ý0m... Ý Ý0;32m OK Ý0m¨ Stopped Ý0;1;39mOpenBSD Secure Shell server Ý0m. Starting Ý0;1;39mOpenBSD Secure Shell server Ý0m... Ý Ý0;32m OK Ý0m¨ Started Ý0;1;39mOpenBSD Secure Shell server Ý0m. Ý Ý0;32m OK Ý0m¨ Finished Ý0;1;39mApply the settings specified in cloud-con ig Ý0m. Ý Ý0;32m OK Ý0m¨ Reached target Ý0;1;39mMulti-User System Ý0m. Ý Ý0;32m OK Ý0m¨ Reached target Ý0;1;39mGraphical Interface Ý0m. Starting Ý0;1;39mExecute cloud user/final scripts Ý0m... Starting Ý0;1;39mRecord Runlevel Change in UTMP Ý0m... Ý Ý0;32m OK Ý0m¨ Finished Ý0;1;39mRecord Runlevel Change in UTMP Ý0m. Ý Ý0;32m OK Ý0m¨ Finished Ý0;1;39mExecute cloud user/final scripts Ý0m. Ý Ý0;32m OK Ý0m¨ Reached target Ý0;1;39mCloud-init target Ý0m. ... Then updated to the latest ISO from today (Aug 15th), I got the same: ... Ý Ý0;32m OK Ý0m¨ Finished Ý0;1;39mHolds Snappy daemon refresh Ý0m. Ý Ý0;32m OK Ý0m¨ Finished Ý0;1;39mService for snap application lxd.activate Ý0m. Ý Ý0;32m OK Ý0m¨ Started Ý0;1;39msnap.lxd.hook.conf -4b29-8a88-87b80c6b731 8.scope Ý0m. Ý Ý0;32m OK Ý0m¨ Started Ý0;1;39msnap.subiquity.hoo -4a63-9355-e4654a5890c 1.scope Ý0m. Ý Ý0;32m OK Ý0m¨ Started Ý0;1;39mService for snap a on subiquity.subiquity -server Ý0m. Ý Ý0;32m OK Ý0m¨ Started Ý0;1;39mService for snap a n subiquity.subiquity- service Ý0m. Starting Ý0;1;39mTime & Date Service Ý0m... Ý Ý0;32m OK Ý0m¨ Started Ý0;1;39mTime & Date Service Ý0m. connecting... - \ | waiting for cloud-init... - \ It is possible to connect to the installer over the network, which might allow the use of a more capable terminal and can offer more languages than can be rendered in the Linux console. Unfortunately this system seems to have no global IP addresses at this time. ... Unfortunately I am not able to get any logs at that (very early) stage of the installation. On top I did a 22.04.1 installation on the same systems, using the same data (IP etc) which worked fine. (I kept one of the systems in that stage for now ...) To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1986551/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1986551] Re: Current kinetic ISO images not installable on s390x
Many thanks all. I guess I need to wait for another day or two until it will have landed in the kinetic ISO, and before I can give it a try ...?! ** Changed in: ubuntu-z-systems Status: New => Fix Committed ** Changed in: subiquity Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1986551 Title: Current kinetic ISO images not installable on s390x Status in cloud-init: Fix Released Status in subiquity: Invalid Status in Ubuntu on IBM z Systems: Fix Committed Bug description: While wanting to install an kinetic/22.10 system on s390x for testing new and updated packages I found that the current daily ISO image for s390x is not installable - not on LPAR nor on z/VM - not interactively using subiquity, not non-interactively using autoinstall. I had the image from August 2nd and the installation ended at the console with these messages (please ignore the weird special characters): ... Ý Ý0;32m OK Ý0m¨ Started Ý0;1;39mTime & Date Service Ý0m. connecting... - \ | waiting for cloud-init... - It is possible to connect to the installer over the network, which might allow the use of a more capable terminal and can offer more languages than can be rendered in the Linux console. Unfortunately this system seems to have no global IP addresses at this time. Starting Ý0;1;39mTime & Date Service Ý0m... Ý Ý0;32m OK Ý0m¨ Started Ý0;1;39mTime & Date Service Ý0m. Ý Ý0;32m OK Ý0m¨ Finished Ý0;1;39mWait until snapd is fully seeded Ý0m. Starting Ý0;1;39mApply the settings specified in cloud-config Ý0m... Ý Ý0;32m OK Ý0m¨ Started Ý0;1;39mSubiquity, the installer for Ubuntu Server hvc0 Ý0m. Ý Ý0;32m OK Ý0m¨ Started Ý0;1;39mSubiquity, the ins er for Ubuntu Server t tysclp0 Ý0m. Ý Ý0;32m OK Ý0m¨ Reached target Ý0;1;39mLogin Prompts Ý0m. Stopping Ý0;1;39mOpenBSD Secure Shell server Ý0m... Ý Ý0;32m OK Ý0m¨ Stopped Ý0;1;39mOpenBSD Secure Shell server Ý0m. Starting Ý0;1;39mOpenBSD Secure Shell server Ý0m... Ý Ý0;32m OK Ý0m¨ Started Ý0;1;39mOpenBSD Secure Shell server Ý0m. Ý Ý0;32m OK Ý0m¨ Finished Ý0;1;39mApply the settings specified in cloud-con ig Ý0m. Ý Ý0;32m OK Ý0m¨ Reached target Ý0;1;39mMulti-User System Ý0m. Ý Ý0;32m OK Ý0m¨ Reached target Ý0;1;39mGraphical Interface Ý0m. Starting Ý0;1;39mExecute cloud user/final scripts Ý0m... Starting Ý0;1;39mRecord Runlevel Change in UTMP Ý0m... Ý Ý0;32m OK Ý0m¨ Finished Ý0;1;39mRecord Runlevel Change in UTMP Ý0m. Ý Ý0;32m OK Ý0m¨ Finished Ý0;1;39mExecute cloud user/final scripts Ý0m. Ý Ý0;32m OK Ý0m¨ Reached target Ý0;1;39mCloud-init target Ý0m. ... Then updated to the latest ISO from today (Aug 15th), I got the same: ... Ý Ý0;32m OK Ý0m¨ Finished Ý0;1;39mHolds Snappy daemon refresh Ý0m. Ý Ý0;32m OK Ý0m¨ Finished Ý0;1;39mService for snap application lxd.activate Ý0m. Ý Ý0;32m OK Ý0m¨ Started Ý0;1;39msnap.lxd.hook.conf -4b29-8a88-87b80c6b731 8.scope Ý0m. Ý Ý0;32m OK Ý0m¨ Started Ý0;1;39msnap.subiquity.hoo -4a63-9355-e4654a5890c 1.scope Ý0m. Ý Ý0;32m OK Ý0m¨ Started Ý0;1;39mService for snap a on subiquity.subiquity -server Ý0m. Ý Ý0;32m OK Ý0m¨ Started Ý0;1;39mService for snap a n subiquity.subiquity- service Ý0m. Starting Ý0;1;39mTime & Date Service Ý0m... Ý Ý0;32m OK Ý0m¨ Started Ý0;1;39mTime & Date Service Ý0m. connecting... - \ | waiting for cloud-init... - \ It is possible to connect to the installer over the network, which might allow the use of a more capable terminal and can offer more languages than can be rendered in the Linux console. Unfortunately this system seems to have no global IP addresses at this time. ... Unfortunately I am not able to get any logs at that (very early) stage of the installation. On top I did a 22.04.1 installation on the same systems, using the same data (IP etc) which worked fine. (I kept one of the systems in that stage for now ...) To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1986551/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1869155] [NEW] Cloud-init uses macaddress keyword on s390x where MAC addresses are not necessarily stable/unique across reboots
Public bug reported:
While performing a subiquity focal installation on an s390x LPAR (where the
LPAR is connected to a VLAN trunk) I saw a section like this:
match:
macaddress: 02:28:0b:00:00:53
So the macaddress keyword is used, but on several s390x machine generation MAC
addresses are
not necessarily stable and uniquie across reboots.
(z14 GA2 and newer system have in between a modified firmware that ensures that
MAC addresses are stable and uniquire across reboots, but for z14 GA 1 and
older systems, incl. the z13 that I used this is not the case - and a backport
of the firmware modification is very unlikely)
The configuration that I found is this:
$ cat /etc/netplan/50-cloud-init.yaml
# This file is generated from information provided by the datasource. Changes
# to it will not persist across an instance reboot. To disable cloud-init's
# network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
ethernets:
enc600:
addresses:
- 10.245.236.26/24
gateway4: 10.245.236.1
match:
macaddress: 02:28:0b:00:00:53
nameservers:
addresses:
- 10.245.236.1
set-name: enc600
version: 2
(This is a spin-off of ticket LP 1868246.)
It's understood that the initial idea for the MAC addresses was to have a
unique identifier, but
I think with the right tooling (ip, ifconfig, ethtool or even the
network-manager UI) you can even change MAC addresses today on other platforms.
Nowadays interface names are based on their underlying physical
device/address (here in this case '600' or to be precise '0600' -
leading '0' are removed), which makes the interface and it's name
already quite unique - since it is not possible to have two devices (in
one system) with the exact same address.
** Affects: cloud-init
Importance: Undecided
Status: New
** Affects: ubuntu-z-systems
Importance: Undecided
Assignee: Canonical Server Team (canonical-server)
Status: New
** Tags: installer s390x
** Also affects: ubuntu-z-systems
Importance: Undecided
Status: New
** Changed in: ubuntu-z-systems
Assignee: (unassigned) => Canonical Server Team (canonical-server)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1869155
Title:
Cloud-init uses macaddress keyword on s390x where MAC addresses are
not necessarily stable/unique across reboots
Status in cloud-init:
New
Status in Ubuntu on IBM z Systems:
New
Bug description:
While performing a subiquity focal installation on an s390x LPAR (where the
LPAR is connected to a VLAN trunk) I saw a section like this:
match:
macaddress: 02:28:0b:00:00:53
So the macaddress keyword is used, but on several s390x machine generation
MAC addresses are
not necessarily stable and uniquie across reboots.
(z14 GA2 and newer system have in between a modified firmware that ensures
that MAC addresses are stable and uniquire across reboots, but for z14 GA 1 and
older systems, incl. the z13 that I used this is not the case - and a backport
of the firmware modification is very unlikely)
The configuration that I found is this:
$ cat /etc/netplan/50-cloud-init.yaml
# This file is generated from information provided by the datasource. Changes
# to it will not persist across an instance reboot. To disable cloud-init's
# network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
ethernets:
enc600:
addresses:
- 10.245.236.26/24
gateway4: 10.245.236.1
match:
macaddress: 02:28:0b:00:00:53
nameservers:
addresses:
- 10.245.236.1
set-name: enc600
version: 2
(This is a spin-off of ticket LP 1868246.)
It's understood that the initial idea for the MAC addresses was to have a
unique identifier, but
I think with the right tooling (ip, ifconfig, ethtool or even the
network-manager UI) you can even change MAC addresses today on other platforms.
Nowadays interface names are based on their underlying physical
device/address (here in this case '600' or to be precise '0600' -
leading '0' are removed), which makes the interface and it's name
already quite unique - since it is not possible to have two devices
(in one system) with the exact same address.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1869155/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe :
[Yahoo-eng-team] [Bug 1868246] Re: No network after subiquity LPAR installation on s390x with VLAN
Some additional information:
Early in the subiquity installation process (right after disk device
enablement) I can see two files in /etc/netplan/:
00-installer-config.yaml
50-cloud-init.yaml.dist-subiquity
I think both are not as they should be for this VLAN environment.
After replacing them with:
network:
version: 2
renderer: networkd
ethernets:
encc000:
dhcp4: no
dhcp6: no
vlans:
encc000.2653:
id: 2653
link: encc000
addresses: [ 10.245.236.15/24 ]
gateway4: 10.245.236.1
nameservers:
search: [ canonical.com ]
addresses:
- 10.245.236.1
I was able to bring up the network (in the subiquity shell) using netplan apply.
(I also disabled/enabled 0.0.c000 - but I think it was not needed).
Unfortunately there is still no network online after the post-install reboot:
$ ip a
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group defaul
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: encc000: mtu 1500 qdisc mq state UP group d
efault qlen 1000
link/ether 16:9e:e9:36:c4:90 brd ff:ff:ff:ff:ff:ff
inet6 fe80::149e:e9ff:fe36:c490/64 scope link
valid_lft forever preferred_lft forever
3: encc000.2653@encc000: mtu 1500 qdisc noqueu
e state UP group default qlen 1000
link/ether 16:9e:e9:36:c4:90 brd ff:ff:ff:ff:ff:ff
inet6 fe80::149e:e9ff:fe36:c490/64 scope link
valid_lft forever preferred_lft forever
...since the following netplan yaml is in place - which is not correct:
$ cat /etc/netplan/50-cloud-init.yaml
# This file is generated from information provided by the datasource. Changes
# to it will not persist across an instance reboot. To disable cloud-init's
# network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
ethernets:
encc000: {}
version: 2
vlans:
encc000.2653:
id: 2653
link: encc000
nameservers:
addresses:
- 10.245.236.1
Replacing it again by the above (known to work) yaml allows to bring the
network up again (with the help of netplan).
I add cloud-init as affected package and let the maintainers decide if
this is a duplicate or not (see previous comment).
** Also affects: cloud-init
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team,
[Yahoo-eng-team] [Bug 1861460] Re: cloud-init should parse initramfs rendered netplan if present
** Also affects: ubuntu-z-systems Importance: Undecided Status: New ** Changed in: ubuntu-z-systems Status: New => In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1861460 Title: cloud-init should parse initramfs rendered netplan if present Status in cloud-init: In Progress Status in Ubuntu on IBM z Systems: In Progress Bug description: initramfs-tools used to only execute klibc based networking with some resolvconf hooks. In recent releases, it has been greatly improved to use isc-dhcp-client instead of klibc, support vlan= key (like in dracut-network), bring up Z devices using chzdev, and generate netplan yaml from all of the above. Above improvements were driven in part by Oracle Cloud and in part by Subiquity netbooting on Z. Thus these days, instead of trying to reparse klibc files in /run/net-*, cloud-init should simply import /run/netplan/$device.yaml files as the ip=* provided networking information on the command line. I do not currently see cloud-init doing that in e.g. /cloudinit/net/cmdline.py To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1861460/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1861412] Re: cloud-init crashes with static network configuration
** Also affects: cloud-init Importance: Undecided Status: New ** No longer affects: cloud-init ** Also affects: ubuntu-z-systems Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1861412 Title: cloud-init crashes with static network configuration Status in Ubuntu on IBM z Systems: New Status in cloud-init package in Ubuntu: New Bug description: I am booting an s390x VM with vlan & static ip= configuration on the kernel command line. It appears that cloudinit is trying to parse the ipconfig results, and is failing. Attaching: cmdline - /proc/cmdline net-encc000.2653.conf - the /run/net-encc000.2653.conf klibc ipconfig state file encc000.2653.yaml - /run/netplan/encc000.2653.yaml which initramfs-tools generates, but cloud-init is not using cloud-init-output.log & cloud-init.log - showing a crash traceback To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1861412/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1839860] Re: cloud-init error while MAAS commissioning (PXE phase) P9 Witherspoon
So after restarting bind9 things work again - dns lookups in petitboot shell, netboot installs (incl. d/l of the installer files), and also MAAS commissioning. Not sure what caused bind9 to run wild. Would be nice to have an option to restart some selected services (like DNS) from the MAAS GUI (as admin). Thanks for your help - closing ticket. ** Changed in: maas Status: Incomplete => Fix Released ** Changed in: ubuntu-power-systems Status: New => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1839860 Title: cloud-init error while MAAS commissioning (PXE phase) P9 Witherspoon Status in cloud-init: Invalid Status in MAAS: Fix Released Status in The Ubuntu-power-systems project: Fix Released Bug description: While trying to commissioning bobone (P9 withersppon machine with OpenBMC in Server team's MAAS) the PXE phase ended with the following cloud-init error (shown at sol): Starting Wait until snapd is fully seeded... Ubuntu 18.04.3 LTS ubuntu hvc0 ubuntu login: [ 131.162174] cloud-init[5497]: Can not apply stage config, no datasource found! Likely bad things to come! [ 131.162320] cloud-init[5497]: [ 131.162414] cloud-init[5497]: Traceback (most recent call last): [ 131.162512] cloud-init[5497]: File "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 485, in main_modules [ 131.162614] cloud-init[5497]: init.fetch(existing="trust") [ 131.162678] cloud-init[5497]: File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 351, in fetch [ 131.162776] cloud-init[5497]: return self._get_data_source(existing=existing) [ 131.162851] cloud-init[5497]: File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 261, in _get_data_source [ 131.162934] cloud-init[5497]: pkg_list, self.reporter) [ 131.163005] cloud-init[5497]: File "/usr/lib/python3/dist-packages/cloudinit/sources/__init__.py", line 741, in find_source [ 131.163104] cloud-init[5497]: raise DataSourceNotFoundException(msg) [ 131.163177] cloud-init[5497]: cloudinit.sources.DataSourceNotFoundException: Did not find any data source, searched classes: () [ 131.163269] cloud-init[5497]: [ 131.53] cloud-init[5551]: Can not apply stage final, no datasource found! Likely bad things to come! [ 131.566820] cloud-init[5551]: [ 131.566922] cloud-init[5551]: Traceback (most recent call last): [ 131.567004] cloud-init[5551]: File "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 485, in main_modules [ 131.567116] cloud-init[5551]: init.fetch(existing="trust") [ 131.567193] cloud-init[5551]: File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 351, in fetch [ 131.567274] cloud-init[5551]: return self._get_data_source(existing=existing) [ 131.567348] cloud-init[5551]: File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 261, in _get_data_source [ 131.567438] cloud-init[5551]: pkg_list, self.reporter) [ 131.567508] cloud-init[5551]: File "/usr/lib/python3/dist-packages/cloudinit/sources/__init__.py", line 741, in find_source [ 131.567598] cloud-init[5551]: raise DataSourceNotFoundException(msg) [ 131.567679] cloud-init[5551]: cloudinit.sources.DataSourceNotFoundException: Did not find any data source, searched classes: () [ 131.567779] cloud-init[5551]: Ubuntu 18.04.3 LTS ubuntu hvc0 ubuntu login: MAAS log (from UI): TIMEEVENT Mon, 12 Aug. 2019 11:10:45 PXE Request - commissioning Mon, 12 Aug. 2019 11:08:43 Node powered on Mon, 12 Aug. 2019 11:08:14 Powering node on Mon, 12 Aug. 2019 11:08:14 Node - Started commissioning on 'bobone'. Mon, 12 Aug. 2019 11:08:14 Node changed status - From 'New' to 'Commissioning' Mon, 12 Aug. 2019 11:08:14 User starting node commissioning - (jfh) Mon, 12 Aug. 2019 11:07:04 Node powered off With that system cannot complete the Commissioning phase. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1839860/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1839860] Re: cloud-init error while MAAS commissioning (PXE phase) P9 Witherspoon
** Also affects: maas Importance: Undecided Status: New ** Also affects: cloud-init Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1839860 Title: cloud-init error while MAAS commissioning (PXE phase) P9 Witherspoon Status in cloud-init: New Status in MAAS: New Status in The Ubuntu-power-systems project: New Bug description: While trying to commissioning bobone (P9 withersppon machine with OpenBMC in Server team's MAAS) the PXE phase ended with the following cloud-init error (shown at sol): Starting Wait until snapd is fully seeded... Ubuntu 18.04.3 LTS ubuntu hvc0 ubuntu login: [ 131.162174] cloud-init[5497]: Can not apply stage config, no datasource found! Likely bad things to come! [ 131.162320] cloud-init[5497]: [ 131.162414] cloud-init[5497]: Traceback (most recent call last): [ 131.162512] cloud-init[5497]: File "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 485, in main_modules [ 131.162614] cloud-init[5497]: init.fetch(existing="trust") [ 131.162678] cloud-init[5497]: File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 351, in fetch [ 131.162776] cloud-init[5497]: return self._get_data_source(existing=existing) [ 131.162851] cloud-init[5497]: File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 261, in _get_data_source [ 131.162934] cloud-init[5497]: pkg_list, self.reporter) [ 131.163005] cloud-init[5497]: File "/usr/lib/python3/dist-packages/cloudinit/sources/__init__.py", line 741, in find_source [ 131.163104] cloud-init[5497]: raise DataSourceNotFoundException(msg) [ 131.163177] cloud-init[5497]: cloudinit.sources.DataSourceNotFoundException: Did not find any data source, searched classes: () [ 131.163269] cloud-init[5497]: [ 131.53] cloud-init[5551]: Can not apply stage final, no datasource found! Likely bad things to come! [ 131.566820] cloud-init[5551]: [ 131.566922] cloud-init[5551]: Traceback (most recent call last): [ 131.567004] cloud-init[5551]: File "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 485, in main_modules [ 131.567116] cloud-init[5551]: init.fetch(existing="trust") [ 131.567193] cloud-init[5551]: File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 351, in fetch [ 131.567274] cloud-init[5551]: return self._get_data_source(existing=existing) [ 131.567348] cloud-init[5551]: File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 261, in _get_data_source [ 131.567438] cloud-init[5551]: pkg_list, self.reporter) [ 131.567508] cloud-init[5551]: File "/usr/lib/python3/dist-packages/cloudinit/sources/__init__.py", line 741, in find_source [ 131.567598] cloud-init[5551]: raise DataSourceNotFoundException(msg) [ 131.567679] cloud-init[5551]: cloudinit.sources.DataSourceNotFoundException: Did not find any data source, searched classes: () [ 131.567779] cloud-init[5551]: Ubuntu 18.04.3 LTS ubuntu hvc0 ubuntu login: MAAS log (from UI): TIMEEVENT Mon, 12 Aug. 2019 11:10:45 PXE Request - commissioning Mon, 12 Aug. 2019 11:08:43 Node powered on Mon, 12 Aug. 2019 11:08:14 Powering node on Mon, 12 Aug. 2019 11:08:14 Node - Started commissioning on 'bobone'. Mon, 12 Aug. 2019 11:08:14 Node changed status - From 'New' to 'Commissioning' Mon, 12 Aug. 2019 11:08:14 User starting node commissioning - (jfh) Mon, 12 Aug. 2019 11:07:04 Node powered off With that system cannot complete the Commissioning phase. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1839860/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1639239] Re: ValueError for Invalid InitiatorConnector in s390
** Changed in: ubuntu-z-systems Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1639239 Title: ValueError for Invalid InitiatorConnector in s390 Status in Ubuntu Cloud Archive: Fix Released Status in Ubuntu Cloud Archive newton series: Fix Committed Status in Ubuntu Cloud Archive ocata series: Fix Released Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) newton series: Fix Released Status in os-brick: Fix Released Status in Ubuntu on IBM z Systems: Fix Released Status in nova package in Ubuntu: Fix Released Status in python-os-brick package in Ubuntu: Fix Released Status in nova source package in Yakkety: Confirmed Status in python-os-brick source package in Yakkety: Confirmed Status in nova source package in Zesty: Fix Released Status in python-os-brick source package in Zesty: Fix Released Bug description: Description === Calling the InitiatorConnector factory results in a ValueError for unsupported protocols, which goes unhandled and may crash a calling service. Steps to reproduce == - clone devstack - make stack Expected result === The nova compute service should run. Actual result = A ValueError is thrown, which, in the case of the nova libvirt driver, is not handled appropriately. The compute service crashes. Environment === os|distro=kvmibm1 os|vendor=kvmibm os|release=1.1.3-beta4.3 git|cinder|master[f6ab36d] git|devstack|master[928b3cd] git|nova|master[56138aa] pip|os-brick|1.7.0 Logs & Configs == [...] 2016-11-03 17:56:57.204 46141 INFO nova.virt.driver [req-fb30a5af-e87c-4ee0-903c-a5aa7d3ad5e3 - -] Loading compute driver 'libvirt.LibvirtDriver' 2016-11-03 17:56:57.442 46141 DEBUG os_brick.initiator.connector [req-fb30a5af-e87c-4ee0-903c-a5aa7d3ad5e3 - -] Factory for ISCSI on s390x factory /usr/lib/python2.7/site-packages/os_brick/initiator/connector.py:261 2016-11-03 17:56:57.444 46141 DEBUG os_brick.initiator.connector [req-fb30a5af-e87c-4ee0-903c-a5aa7d3ad5e3 - -] Factory for ISCSI on s390x factory /usr/lib/python2.7/site-packages/os_brick/initiator/connector.py:261 2016-11-03 17:56:57.445 46141 DEBUG os_brick.initiator.connector [req-fb30a5af-e87c-4ee0-903c-a5aa7d3ad5e3 - -] Factory for ISER on s390x factory /usr/lib/python2.7/site-packages/os_brick/initiator/connector.py:261 2016-11-03 17:56:57.445 46141 CRITICAL nova [req-fb30a5af-e87c-4ee0-903c-a5aa7d3ad5e3 - -] ValueError: Invalid InitiatorConnector protocol specified ISER 2016-11-03 17:56:57.445 46141 ERROR nova Traceback (most recent call last): 2016-11-03 17:56:57.445 46141 ERROR nova File "/usr/bin/nova-compute", line 10, in 2016-11-03 17:56:57.445 46141 ERROR nova sys.exit(main()) 2016-11-03 17:56:57.445 46141 ERROR nova File "/opt/stack/nova/nova/cmd/compute.py", line 56, in main 2016-11-03 17:56:57.445 46141 ERROR nova topic=CONF.compute_topic) 2016-11-03 17:56:57.445 46141 ERROR nova File "/opt/stack/nova/nova/service.py", line 216, in create 2016-11-03 17:56:57.445 46141 ERROR nova periodic_interval_max=periodic_interval_max) 2016-11-03 17:56:57.445 46141 ERROR nova File "/opt/stack/nova/nova/service.py", line 91, in __init__ 2016-11-03 17:56:57.445 46141 ERROR nova self.manager = manager_class(host=self.host, *args, **kwargs) 2016-11-03 17:56:57.445 46141 ERROR nova File "/opt/stack/nova/nova/compute/manager.py", line 537, in __init__ 2016-11-03 17:56:57.445 46141 ERROR nova self.driver = driver.load_compute_driver(self.virtapi, compute_driver) 2016-11-03 17:56:57.445 46141 ERROR nova File "/opt/stack/nova/nova/virt/driver.py", line 1625, in load_compute_driver 2016-11-03 17:56:57.445 46141 ERROR nova virtapi) 2016-11-03 17:56:57.445 46141 ERROR nova File "/usr/lib/python2.7/site-packages/oslo_utils/importutils.py", line 44, in import_object 2016-11-03 17:56:57.445 46141 ERROR nova return import_class(import_str)(*args, **kwargs) 2016-11-03 17:56:57.445 46141 ERROR nova File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 356, in __init__ 2016-11-03 17:56:57.445 46141 ERROR nova self._get_volume_drivers(), self._host) 2016-11-03 17:56:57.445 46141 ERROR nova File "/opt/stack/nova/nova/virt/driver.py", line 44, in driver_dict_from_config 2016-11-03 17:56:57.445 46141 ERROR nova driver_registry[driver_type] = driver_class(*args, **kwargs) 2016-11-03 17:56:57.445 46141 ERROR nova File "/opt/stack/nova/nova/virt/libvirt/volume/iser.py", line 34, in __init__ 2016-11-03 17:56:57.445 46141 ERROR nova transport=self._get_transport()) 2016-11-03 17:56:57.445 46141 ERROR nova File
[Yahoo-eng-team] [Bug 1639239] Re: ValueError for Invalid InitiatorConnector in s390
** Also affects: ubuntu-z-systems Importance: Undecided Status: New ** Changed in: ubuntu-z-systems Status: New => Confirmed ** Changed in: ubuntu-z-systems Importance: Undecided => Medium ** Tags added: openstack-ibm -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1639239 Title: ValueError for Invalid InitiatorConnector in s390 Status in Ubuntu Cloud Archive: Confirmed Status in Ubuntu Cloud Archive newton series: Confirmed Status in OpenStack Compute (nova): Fix Released Status in os-brick: Fix Released Status in Ubuntu on IBM z Systems: Confirmed Status in nova package in Ubuntu: Fix Released Status in python-os-brick package in Ubuntu: Fix Released Status in nova source package in Yakkety: Confirmed Status in python-os-brick source package in Yakkety: Confirmed Status in nova source package in Zesty: Fix Released Status in python-os-brick source package in Zesty: Fix Released Bug description: Description === Calling the InitiatorConnector factory results in a ValueError for unsupported protocols, which goes unhandled and may crash a calling service. Steps to reproduce == - clone devstack - make stack Expected result === The nova compute service should run. Actual result = A ValueError is thrown, which, in the case of the nova libvirt driver, is not handled appropriately. The compute service crashes. Environment === os|distro=kvmibm1 os|vendor=kvmibm os|release=1.1.3-beta4.3 git|cinder|master[f6ab36d] git|devstack|master[928b3cd] git|nova|master[56138aa] pip|os-brick|1.7.0 Logs & Configs == [...] 2016-11-03 17:56:57.204 46141 INFO nova.virt.driver [req-fb30a5af-e87c-4ee0-903c-a5aa7d3ad5e3 - -] Loading compute driver 'libvirt.LibvirtDriver' 2016-11-03 17:56:57.442 46141 DEBUG os_brick.initiator.connector [req-fb30a5af-e87c-4ee0-903c-a5aa7d3ad5e3 - -] Factory for ISCSI on s390x factory /usr/lib/python2.7/site-packages/os_brick/initiator/connector.py:261 2016-11-03 17:56:57.444 46141 DEBUG os_brick.initiator.connector [req-fb30a5af-e87c-4ee0-903c-a5aa7d3ad5e3 - -] Factory for ISCSI on s390x factory /usr/lib/python2.7/site-packages/os_brick/initiator/connector.py:261 2016-11-03 17:56:57.445 46141 DEBUG os_brick.initiator.connector [req-fb30a5af-e87c-4ee0-903c-a5aa7d3ad5e3 - -] Factory for ISER on s390x factory /usr/lib/python2.7/site-packages/os_brick/initiator/connector.py:261 2016-11-03 17:56:57.445 46141 CRITICAL nova [req-fb30a5af-e87c-4ee0-903c-a5aa7d3ad5e3 - -] ValueError: Invalid InitiatorConnector protocol specified ISER 2016-11-03 17:56:57.445 46141 ERROR nova Traceback (most recent call last): 2016-11-03 17:56:57.445 46141 ERROR nova File "/usr/bin/nova-compute", line 10, in 2016-11-03 17:56:57.445 46141 ERROR nova sys.exit(main()) 2016-11-03 17:56:57.445 46141 ERROR nova File "/opt/stack/nova/nova/cmd/compute.py", line 56, in main 2016-11-03 17:56:57.445 46141 ERROR nova topic=CONF.compute_topic) 2016-11-03 17:56:57.445 46141 ERROR nova File "/opt/stack/nova/nova/service.py", line 216, in create 2016-11-03 17:56:57.445 46141 ERROR nova periodic_interval_max=periodic_interval_max) 2016-11-03 17:56:57.445 46141 ERROR nova File "/opt/stack/nova/nova/service.py", line 91, in __init__ 2016-11-03 17:56:57.445 46141 ERROR nova self.manager = manager_class(host=self.host, *args, **kwargs) 2016-11-03 17:56:57.445 46141 ERROR nova File "/opt/stack/nova/nova/compute/manager.py", line 537, in __init__ 2016-11-03 17:56:57.445 46141 ERROR nova self.driver = driver.load_compute_driver(self.virtapi, compute_driver) 2016-11-03 17:56:57.445 46141 ERROR nova File "/opt/stack/nova/nova/virt/driver.py", line 1625, in load_compute_driver 2016-11-03 17:56:57.445 46141 ERROR nova virtapi) 2016-11-03 17:56:57.445 46141 ERROR nova File "/usr/lib/python2.7/site-packages/oslo_utils/importutils.py", line 44, in import_object 2016-11-03 17:56:57.445 46141 ERROR nova return import_class(import_str)(*args, **kwargs) 2016-11-03 17:56:57.445 46141 ERROR nova File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 356, in __init__ 2016-11-03 17:56:57.445 46141 ERROR nova self._get_volume_drivers(), self._host) 2016-11-03 17:56:57.445 46141 ERROR nova File "/opt/stack/nova/nova/virt/driver.py", line 44, in driver_dict_from_config 2016-11-03 17:56:57.445 46141 ERROR nova driver_registry[driver_type] = driver_class(*args, **kwargs) 2016-11-03 17:56:57.445 46141 ERROR nova File "/opt/stack/nova/nova/virt/libvirt/volume/iser.py", line 34, in __init__ 2016-11-03 17:56:57.445 46141 ERROR nova transport=self._get_transport()) 2016-11-03 17:56:57.445 46141 ERROR nova File
[Yahoo-eng-team] [Bug 1575055] Re: check_instance_id() error on reboots when using config-drive
** Changed in: ubuntu-z-systems Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1575055 Title: check_instance_id() error on reboots when using config-drive Status in cloud-init: Fix Committed Status in Ubuntu on IBM z Systems: Fix Released Status in cloud-init package in Ubuntu: Fix Released Status in cloud-init source package in Xenial: Fix Released Bug description: Problem Description = When using a config-drive to provide meta-data to cloud-init on ubuntu (for Linux guest running in KVM for z Systems) we get a check_instance_id() error whenever we soft reboot after the (successful) initial boot. The error shows: [5.283203] cloud-init[1637]: Cloud-init v. 0.7.7 running 'init-local' at Sat, 23 Apr 2016 00:50:58 +. Up 5.25 seconds. [5.283368] cloud-init[1637]: 2016-04-22 20:50:58,839 - util.py[WARNING]: failed of stage init-local [5.286659] cloud-init[1637]: failed run of stage init-local [5.286770] cloud-init[1637]: [5.286849] cloud-init[1637]: Traceback (most recent call last): [5.286924] cloud-init[1637]: File "/usr/bin/cloud-init", line 520, in status_wrapper [5.286998] cloud-init[1637]: ret = functor(name, args) [5.287079] cloud-init[1637]: File "/usr/bin/cloud-init", line 250, in main_init [5.287152] cloud-init[1637]: init.fetch(existing=existing) [5.287225] cloud-init[1637]: File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 322, in fetch [5.287298] cloud-init[1637]: return self._get_data_source(existing=existing) [5.287371] cloud-init[1637]: File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 229, in _get_data_source [5.287445] cloud-init[1637]: ds.check_instance_id(self.cfg)): [5.287518] cloud-init[1637]: TypeError: check_instance_id() takes 1 positional argument but 2 were given [5.287592] cloud-init[1637]: [FAILED] Failed to start Initial cloud-init job (pre-networking). The failure of the init-local pre-networking does seem to lead to a boot up delay as cloud-init tries to search for networking outside of the already saved networking data. Otherwise the error is purely cosmetic as later init modules find (or let existing IP configuration take over) and bring up the correct interfaces. The original problem was found outside of openstack with stand-alone cloud-config iso images. But have been able to reproduce the problem within an openstack ICM environment. Team has had some success getting around the problem by patching the check_instance_id function in /usr/lib/python3/dist- packages/cloudinit/sources/DataSourceConfigDrive.py so that it accepted an extra argument, ex: ubuntu@markvercd:~$ sudo cat check_instance_id.patch --- /usr/lib/python3/dist-packages/cloudinit/sources/DataSourceConfigDrive.py 2016-04-06 15:29:59.0 + +++ /usr/lib/python3/dist-packages/cloudinit/sources/DataSourceConfigDrive.py.new 2016-04-11 22:53:47.799867139 + @@ -155,7 +155,7 @@ return True -def check_instance_id(self): +def check_instance_id(self,somecfg): # quickly (local check only) if self.instance_id is still valid return sources.instance_id_matches_system_uuid(self.get_instance_id()) ubuntu@markvercd:~$ ---uname output--- Linux k6mpathcl.pokprv.stglabs.ibm.com 4.4.0-21-generic #37-Ubuntu SMP Mon Apr 18 18:31:26 UTC 2016 s390x s390x s390x GNU/Linux Machine Type = KVM guest on a z13 (2827-732) LPAR Steps to Reproduce = 1) set up ubuntu guest image with cloud-init 2) pass in iso image with cloud-config data in cdrom device 3) boot up successfully with cloud-config data 4) attempt a soft reboot. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1575055/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1575055] Re: check_instance_id() error on reboots when using config-drive
** Also affects: ubuntu-z-systems Importance: Undecided Status: New ** Changed in: ubuntu-z-systems Status: New => Fix Committed ** Changed in: ubuntu-z-systems Importance: Undecided => Medium -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1575055 Title: check_instance_id() error on reboots when using config-drive Status in cloud-init: Fix Committed Status in Ubuntu on IBM z Systems: Fix Committed Status in cloud-init package in Ubuntu: Fix Released Status in cloud-init source package in Xenial: Confirmed Bug description: Problem Description = When using a config-drive to provide meta-data to cloud-init on ubuntu (for Linux guest running in KVM for z Systems) we get a check_instance_id() error whenever we soft reboot after the (successful) initial boot. The error shows: [5.283203] cloud-init[1637]: Cloud-init v. 0.7.7 running 'init-local' at Sat, 23 Apr 2016 00:50:58 +. Up 5.25 seconds. [5.283368] cloud-init[1637]: 2016-04-22 20:50:58,839 - util.py[WARNING]: failed of stage init-local [5.286659] cloud-init[1637]: failed run of stage init-local [5.286770] cloud-init[1637]: [5.286849] cloud-init[1637]: Traceback (most recent call last): [5.286924] cloud-init[1637]: File "/usr/bin/cloud-init", line 520, in status_wrapper [5.286998] cloud-init[1637]: ret = functor(name, args) [5.287079] cloud-init[1637]: File "/usr/bin/cloud-init", line 250, in main_init [5.287152] cloud-init[1637]: init.fetch(existing=existing) [5.287225] cloud-init[1637]: File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 322, in fetch [5.287298] cloud-init[1637]: return self._get_data_source(existing=existing) [5.287371] cloud-init[1637]: File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 229, in _get_data_source [5.287445] cloud-init[1637]: ds.check_instance_id(self.cfg)): [5.287518] cloud-init[1637]: TypeError: check_instance_id() takes 1 positional argument but 2 were given [5.287592] cloud-init[1637]: [FAILED] Failed to start Initial cloud-init job (pre-networking). The failure of the init-local pre-networking does seem to lead to a boot up delay as cloud-init tries to search for networking outside of the already saved networking data. Otherwise the error is purely cosmetic as later init modules find (or let existing IP configuration take over) and bring up the correct interfaces. The original problem was found outside of openstack with stand-alone cloud-config iso images. But have been able to reproduce the problem within an openstack ICM environment. Team has had some success getting around the problem by patching the check_instance_id function in /usr/lib/python3/dist- packages/cloudinit/sources/DataSourceConfigDrive.py so that it accepted an extra argument, ex: ubuntu@markvercd:~$ sudo cat check_instance_id.patch --- /usr/lib/python3/dist-packages/cloudinit/sources/DataSourceConfigDrive.py 2016-04-06 15:29:59.0 + +++ /usr/lib/python3/dist-packages/cloudinit/sources/DataSourceConfigDrive.py.new 2016-04-11 22:53:47.799867139 + @@ -155,7 +155,7 @@ return True -def check_instance_id(self): +def check_instance_id(self,somecfg): # quickly (local check only) if self.instance_id is still valid return sources.instance_id_matches_system_uuid(self.get_instance_id()) ubuntu@markvercd:~$ ---uname output--- Linux k6mpathcl.pokprv.stglabs.ibm.com 4.4.0-21-generic #37-Ubuntu SMP Mon Apr 18 18:31:26 UTC 2016 s390x s390x s390x GNU/Linux Machine Type = KVM guest on a z13 (2827-732) LPAR Steps to Reproduce = 1) set up ubuntu guest image with cloud-init 2) pass in iso image with cloud-config data in cdrom device 3) boot up successfully with cloud-config data 4) attempt a soft reboot. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1575055/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
