[Yahoo-eng-team] [Bug 1774666] Re: Bond interfaces stuck at 1500 MTU on Bionic
** No longer affects: netplan.io (Ubuntu Cosmic) -- 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/1774666 Title: Bond interfaces stuck at 1500 MTU on Bionic Status in cloud-init: Fix Released Status in MAAS: Invalid Status in cloud-init package in Ubuntu: Fix Released Status in cloud-init source package in Xenial: Confirmed Status in cloud-init source package in Artful: Confirmed Status in cloud-init source package in Bionic: Confirmed Status in cloud-init source package in Cosmic: Fix Released Bug description: When deploying a machine through MAAS with bonded network interfaces, the bond does not have a 9000 byte MTU applied despite the attached VLANs having had a 9000 MTU explicitly set. The MTU size is set on the bond members, but not on the bond itself in Netplan. Consequently, when the bond is brought up, the interface MTU is decreased from 9000 to 1500. Manually changing the interface MTU after boot is successful. This is not observed when deploying Xenial on the same machine. The bond comes up at the expected 9000 byte MTU. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1774666/+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 1774666] Re: Bond interfaces stuck at 1500 MTU on Bionic
** No longer affects: netplan.io (Ubuntu) ** No longer affects: netplan.io (Ubuntu Xenial) ** No longer affects: netplan.io (Ubuntu Artful) ** No longer affects: netplan.io (Ubuntu Bionic) -- 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/1774666 Title: Bond interfaces stuck at 1500 MTU on Bionic Status in cloud-init: Fix Released Status in MAAS: Invalid Status in cloud-init package in Ubuntu: Fix Released Status in cloud-init source package in Xenial: Confirmed Status in cloud-init source package in Artful: Confirmed Status in cloud-init source package in Bionic: Confirmed Status in cloud-init source package in Cosmic: Fix Released Bug description: When deploying a machine through MAAS with bonded network interfaces, the bond does not have a 9000 byte MTU applied despite the attached VLANs having had a 9000 MTU explicitly set. The MTU size is set on the bond members, but not on the bond itself in Netplan. Consequently, when the bond is brought up, the interface MTU is decreased from 9000 to 1500. Manually changing the interface MTU after boot is successful. This is not observed when deploying Xenial on the same machine. The bond comes up at the expected 9000 byte MTU. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1774666/+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 1771885] Re: bionic: static maas missing search domain in systemd-resolve configuration
Given the workaround available for maas & cloud-init this is working as expected. Thanks for the debugging everyone. ** Changed in: cloud-init Status: New => Won't Fix ** Changed in: maas Status: Incomplete => 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/1771885 Title: bionic: static maas missing search domain in systemd-resolve configuration Status in cloud-init: Won't Fix Status in juju: Fix Committed Status in juju 2.3 series: Fix Released Status in MAAS: Invalid Bug description: juju: 2.4-beta2 MAAS: 2.3.0 Testing deployment of LXD containers on bionic (specifically for an openstack deployment) lead to this problem: https://bugs.launchpad.net/charm-nova-cloud-controller/+bug/1765405 Summary: previously, the DNS config in the LXD containers were the same as the host machines now, the DNS config is in systemd, the DNS server is set correctly, but the search domain is missing, so hostnames won't resolve. Working resolv.conf on xenial lxd container: nameserver 10.245.168.6 search maas Non-working "systemd-resolve --status": ... Link 21 (eth0) Current Scopes: DNS LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no DNS Servers: 10.245.168.6 Working (now able to resolve hostnames after modifying netplan and adding search domain): Link 21 (eth0) Current Scopes: DNS LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no DNS Servers: 10.245.168.6 DNS Domain: maas ubuntu@juju-6406ff-2-lxd-2:/etc$ host node-name node-name.maas has address 10.245.168.0 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1771885/+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 1774056] Re: Nodes fail to deploy at ''cloudinit'' running modules for final'
** Changed in: cloud-init Status: Incomplete => 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/1774056 Title: Nodes fail to deploy at ''cloudinit'' running modules for final' Status in cloud-init: Invalid Bug description: machine-status: current: provisioning error message: 'Failed deployment: ''cloudinit'' running modules for final' No other errors seem detectable in the logs for that node. We require some expert triage for this one. I have attached all of the logs for one of the failing runs. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1774056/+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 1600766] Re: initial dhcp has default hostname of ubuntu
** Changed in: cloud-init (Ubuntu) Status: Confirmed => Won't Fix ** Changed in: cloud-init Status: Confirmed => Won't Fix -- 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/1600766 Title: initial dhcp has default hostname of ubuntu Status in cloud-init: Won't Fix Status in juju: Invalid Status in cloud-init package in Ubuntu: Won't Fix Bug description: When using the normal lxd-bridge, using a dnsmasq instance for dhcp, the initial dhcp is always the hostname 'ubuntu', and this is recorded in the dnsmasq's dhcp leases file. Presumably the dhcp is done before the container's hostname is set. A restart or dhcp renew seems to put the correct container name in the leases file. This is a problem when using the dnsmasq for local dns resolving for *.lxd, which is the standard way of doing host dns for containers, as new containers are not dns addressable without a restart or renew. Is there anyway get the correct hostname in the initial dhcp? Or maybe renew after setting the hostname? Related Bugs: * LXC/LXD Issue https://github.com/lxc/lxd/issues/2244 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1600766/+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 1743212] Re: SSL Cert for cloud-init.org invalid
Cert has been fixed. ** Changed in: cloud-init Status: Confirmed => 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/1743212 Title: SSL Cert for cloud-init.org invalid Status in cloud-init: Fix Released Bug description: If I visit cloud-init.org i get a cert that is only valid for cloud-init.io. Is the .org site legitimate or a bogus site? Is it a simple misconfiguration? I reached the .org site through Google, so it must be popular in some sense. A picture is worth a thousand words, so have a look at the attached screenshot. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1743212/+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 1731868] Re: vmware reported as 'EC2', 'None'
Hi Merlijn I added the cloud-init project on here, and we will target cloud-init 17.2 for this fix. Just so you know, this is currently a *warning* and your system should be usable even with this warning message displaying when you log in. If you find that it's blocking you (other than being annoying), please do comment back. Thanks for reporting this and helping to make Ubuntu better! ** Also affects: cloud-init Importance: Undecided Status: New ** Changed in: cloud-init Milestone: None => 17.2 ** Changed in: cloud-init Assignee: (unassigned) => Chad Smith (chad.smith) ** Changed in: cloud-init (Ubuntu) Assignee: Scott Moser (smoser) => Chad Smith (chad.smith) ** Changed in: cloud-init Importance: Undecided => High ** Changed in: cloud-init Status: New => In Progress ** Changed in: cloud-init (Ubuntu) Status: New => Triaged -- 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/1731868 Title: vmware reported as 'EC2', 'None' Status in cloud-init: In Progress Status in cloud-init package in Ubuntu: Triaged Bug description: Just bootstrapped a Juju controller on a Vmware vsphere cloud and I got a message from cloud-init that the system identified the datasource as ec2. Hypervisor: VMware ESXi, 6.5.0, 5310538 ** # A new feature in cloud-init identified possible datasources for# # this system as:# # ['Ec2', 'None'] # # However, the datasource used was: OVF # ## # In the future, cloud-init will only attempt to use datasources that# # are identified or specifically configured. # # For more information see # # https://bugs.launchpad.net/bugs/1669675 # ## # If you are seeing this message, please file a bug against # # cloud-init at # #https://bugs.launchpad.net/cloud-init/+filebug?field.tags=dsid # # Make sure to include the cloud provider your instance is # # running on.# ## # After you have filed a bug, you can disable this warning by launching # # your instance with the cloud-config below, or putting that content # # into /etc/cloud/cloud.cfg.d/99-warnings.cfg# ## # #cloud-config # # warnings: # # dsid_missing_source: off # ** To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1731868/+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 1727358] Re: cloud-init is slow to complete init on minimized images
Marking as wont-fix for cloud-init for now as that would be a workaround
for the base problem that is not desired right now. Adding linux-kvm to
evaluate why this difference exists between linux-generic and linux-kvm
** Changed in: cloud-init
Status: Incomplete => Won't Fix
** Also affects: linux-kvm (Ubuntu)
Importance: Undecided
Status: New
** Changed in: cloud-init (Ubuntu)
Status: Triaged => Won't Fix
--
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/1727358
Title:
cloud-init is slow to complete init on minimized images
Status in cloud-init:
Won't Fix
Status in cloud-init package in Ubuntu:
Won't Fix
Status in linux-kvm package in Ubuntu:
New
Status in python3.6 package in Ubuntu:
Triaged
Bug description:
http://paste.ubuntu.com/25816789/ for the full logs.
cloud-init is very slow to complete its initialization steps.
Specifically, the 'init' takes over 150 seconds.
Cloud-init v. 17.1 running 'init-local' at Wed, 25 Oct 2017 13:22:07 +.
Up 2.39 seconds.
2017-10-25 13:22:07,157 - util.py[WARNING]: did not find either path
/sys/class/dmi/id or dmidecode command
Cloud-init v. 17.1 running 'init' at Wed, 25 Oct 2017 13:22:16 +. Up
11.37 seconds.
ci-info: Net device
info+
ci-info:
++---+-+---+---+---+
ci-info: | Device | Up | Address | Mask | Scope |
Hw-Address|
ci-info:
++---+-+---+---+---+
ci-info: | ens3: | True | 192.168.100.161 | 255.255.255.0 | . |
52:54:00:bb:ad:fb |
ci-info: | ens3: | True |.| . | d |
52:54:00:bb:ad:fb |
ci-info: | lo: | True |127.0.0.1| 255.0.0.0 | . |
. |
ci-info: | lo: | True |.| . | d |
. |
ci-info: | sit0: | False |.| . | . |
. |
ci-info:
++---+-+---+---+---+
ci-info: Route IPv4
info
ci-info:
+---+---+---+-+---+---+
ci-info: | Route | Destination |Gateway| Genmask |
Interface | Flags |
ci-info:
+---+---+---+-+---+---+
ci-info: | 0 |0.0.0.0| 192.168.100.1 | 0.0.0.0 |ens3
| UG |
ci-info: | 1 | 192.168.100.0 |0.0.0.0| 255.255.255.0 |ens3
| U |
ci-info: | 2 | 192.168.100.1 |0.0.0.0| 255.255.255.255 |ens3
| UH |
ci-info:
+---+---+---+-+---+---+
2017-10-25 13:24:38,187 - util.py[WARNING]: Failed to resize filesystem
(cmd=('resize2fs', '/dev/root'))
2017-10-25 13:24:38,193 - util.py[WARNING]: Running module resizefs () failed
Generating public/private rsa key pair.
Your identification has been saved in /etc/ssh/ssh_host_rsa_key.
Your public key has been saved in /etc/ssh/ssh_host_rsa_key.pub.
The key fingerprint is:
SHA256:LKNlCqqOgPB8KBKGfPhFO5Rs6fDMnAvVet/W9i4vLxY root@cloudimg
The key's randomart image is:
+---[RSA 2048]+
| |
|. + |
| . O . |
|o . % +. |
|++.o %=.S|
|+=ooo=+o. . .E |
|* +.+. . o o. |
|=. . . .=. |
|+. . B= |
+[SHA256]-+
Generating public/private dsa key pair.
Your identification has been saved in /etc/ssh/ssh_host_dsa_key.
Your public key has been saved in /etc/ssh/ssh_host_dsa_key.pub.
The key fingerprint is:
SHA256:dNWNyBHqTUCl820/vL0dEhOVDFYJzqr1WeuqV1PAmjk root@cloudimg
The key's randomart image is:
+---[DSA 1024]+
| .oo=X==o|
| =* *+.|
|. = .B . |
| . o =E.. .|
|S .oo+o..|
| o ..*+.|
| . +.=o|
| .o *|
| .o..++|
+[SHA256]-+
Generating public/private ecdsa key pair.
Your identification has been saved in /etc/ssh/ssh_host_ecdsa_key.
Your public key has been saved in /etc/ssh/ssh_host_ecdsa_key.pub.
The key fingerprint is:
SHA256:N3RTlPa7KU5ryq6kJAO8Tiq90ub4P1DGSofn6jFkM3k root@cloudimg
The key's randomart image is:
+---[ECDSA 256]---+
| .o. |
| .o |
| o . o. . |
| +.*. . . .|
| .*XE S o .|
| oo++. . . |
| oo= o . . . o|
|o.Oo. + o . .o.o |
|oB=+.. . .o++o. |
+[SHA256]-+
Generating public/private ed25519 key pair.
Your identification has been saved in /etc/ssh/ssh_host_ed25519_key.
Your public key has been saved in /etc/ssh/ssh_host
[Yahoo-eng-team] [Bug 1701225] Re: cloud-init datasource using ec2 in openstack
Closed per submitter request. Feel free to re-open or re-file if seen
in the future.
** Changed in: cloud-init
Status: Incomplete => 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/1701225
Title:
cloud-init datasource using ec2 in openstack
Status in cloud-init:
Invalid
Bug description:
Spinning up an instance on a Canonical-internal OpenStack instance
running Icehouse I see this message when I ssh into it:
https://pastebin.canonical.com/192210/
$ dpkg-query -W -f='${Version}' cloud-init
0.7.9-153-g16a7302f-0ubuntu1~16.04.1
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1701225/+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 1701297] Re: NTP reload failure (unable to read library) on overlayfs
** Changed in: cloud-init Status: Incomplete => Won't Fix -- 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/1701297 Title: NTP reload failure (unable to read library) on overlayfs Status in cloud-init: Won't Fix Status in apparmor package in Ubuntu: Confirmed Status in cloud-init package in Ubuntu: Incomplete Status in linux package in Ubuntu: Confirmed Bug description: After update [1] of cloud-init in Ubuntu (which landed in xenial- updates on 2017-06-27), it is causing NTP reload failures. https://launchpad.net/ubuntu/+source/cloud-init/0.7.9-153-g16a7302f- 0ubuntu1~16.04.1 In MAAS scenarios, this is causing the machine to fail to deploy. Related bugs: * bug 1645644: cloud-init ntp not using expected servers To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1701297/+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 1690430] Re: [Hyper-V] Advanced networking support on Azure
** Also affects: cloud-init (Ubuntu) Importance: Undecided Status: New ** Merge proposal linked: https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/326373 ** Changed in: cloud-init Status: New => Fix Committed -- 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/1690430 Title: [Hyper-V] Advanced networking support on Azure Status in cloud-init: Fix Committed Status in cloud-init package in Ubuntu: New Bug description: We are in the process of rolling out SR-IOV in Azure (available as a preview now, contact me offline and we can work out getting your subscription addedif you want to try it). In general our normal synthetic interface appears as eth0 and the VF comes in as eth1. We intend to bond these interfaces together so that if the VF goes down, or the VM is migrated to where no VF is present, eth0 remains as the valid default interface. At the moment we are handling the bonding via this script: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/plain/tools/hv/bondvf.sh We were looking at ways to either integrate the behavior into cloud- init or invoke the script from cloud-init and do the right thing. We recently observed after https://bugs.launchpad.net/ubuntu/+source /cloud-init/+bug/1669860 that the VF interface gets renamed to something like "enP1p0s2" but more recently as "rename2". Is it possible that 1669860 needs to be expanded to cover our case or is there something we should be doing to make sure that change is working properly for SR-IOV in Azure? To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1690430/+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 1690430] Re: [Hyper-V] VF renaming on Azure
There is an SRU in progress [ubuntu/xenial-proposed] cloud-init 0.7.9-153-g16a7302f-0ubuntu1~16.04.2 (Waiting for approval) [ubuntu/yakkety-proposed] cloud-init 0.7.9-153-g16a7302f-0ubuntu1~16.10.2 (Waiting for approval) [ubuntu/zesty-proposed] cloud-init 0.7.9-153-g16a7302f-0ubuntu1~17.04.2 (Waiting for approval) That will address the blocking portion of this bug. The interfaces will not be bonded, but the instance will boot with basic networking and allow anyone to bond the interfaces as a post-boot step however they would like. A more advanced solution will be proposed. ** Also affects: cloud-init Importance: Undecided Status: New ** No longer affects: udev (Ubuntu) ** Changed in: cloud-init Importance: Undecided => High ** Summary changed: - [Hyper-V] VF renaming on Azure + [Hyper-V] Advanced networking support on Azure -- 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/1690430 Title: [Hyper-V] Advanced networking support on Azure Status in cloud-init: New Bug description: We are in the process of rolling out SR-IOV in Azure (available as a preview now, contact me offline and we can work out getting your subscription addedif you want to try it). In general our normal synthetic interface appears as eth0 and the VF comes in as eth1. We intend to bond these interfaces together so that if the VF goes down, or the VM is migrated to where no VF is present, eth0 remains as the valid default interface. At the moment we are handling the bonding via this script: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/plain/tools/hv/bondvf.sh We were looking at ways to either integrate the behavior into cloud- init or invoke the script from cloud-init and do the right thing. We recently observed after https://bugs.launchpad.net/ubuntu/+source /cloud-init/+bug/1669860 that the VF interface gets renamed to something like "enP1p0s2" but more recently as "rename2". Is it possible that 1669860 needs to be expanded to cover our case or is there something we should be doing to make sure that change is working properly for SR-IOV in Azure? To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1690430/+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 1693361] Re: cloud-init sometimes fails on dpkg lock due to concurrent apt-daily.service execution
** Bug watch added: Debian Bug tracker #864681 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864681 ** Also affects: apt via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864681 Importance: Unknown Status: Unknown -- 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/1693361 Title: cloud-init sometimes fails on dpkg lock due to concurrent apt- daily.service execution Status in APT: Unknown Status in cloud-init: Confirmed Status in apt package in Ubuntu: New Status in cloud-init package in Ubuntu: Confirmed Status in cloud-init source package in Xenial: Confirmed Status in cloud-init source package in Yakkety: Confirmed Status in cloud-init source package in Zesty: Confirmed Status in cloud-init source package in Artful: Confirmed Bug description: apt-daily is now a systemd service rather than being invoked by cron.daily. If one builds a custom AMI it is possible that the apt- daily.timer will fire during boot. This can fire at the same time cloud-init is running and if cloud-init loses the race the invocation of apt (e.g. use of "packages:" in the config) will fail. There is a lot of discussion online about this change to apt-daily (e.g. unattended upgrades happening during business hours, delaying boot, etc.) and discussion of potential systemd changes regarding timers firing during boot (c.f. https://github.com/systemd/systemd/issues/5659). While it would be better to solve this in apt itself, I suggest that cloud-init be defensive when calling apt and implement some retry mechanism. Various instances of people running into this issue: https://github.com/chef/bento/issues/609 https://clusterhq.atlassian.net/browse/FLOC-4486 https://github.com/boxcutter/ubuntu/issues/73 https://unix.stackexchange.com/questions/315502/how-to-disable-apt-daily-service-on-ubuntu-cloud-vm-image To manage notifications about this bug go to: https://bugs.launchpad.net/apt/+bug/1693361/+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 1693361] Re: cloud-init sometimes fails on dpkg lock due to concurrent apt-daily.service execution
** Also affects: apt (Ubuntu) Importance: Undecided Status: New ** No longer affects: apt (Ubuntu Zesty) ** No longer affects: apt (Ubuntu Yakkety) ** No longer affects: apt (Ubuntu Xenial) ** No longer affects: apt (Ubuntu Artful) -- 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/1693361 Title: cloud-init sometimes fails on dpkg lock due to concurrent apt- daily.service execution Status in cloud-init: Confirmed Status in apt package in Ubuntu: New Status in cloud-init package in Ubuntu: Confirmed Status in cloud-init source package in Xenial: Confirmed Status in cloud-init source package in Yakkety: Confirmed Status in cloud-init source package in Zesty: Confirmed Status in cloud-init source package in Artful: Confirmed Bug description: apt-daily is now a systemd service rather than being invoked by cron.daily. If one builds a custom AMI it is possible that the apt- daily.timer will fire during boot. This can fire at the same time cloud-init is running and if cloud-init loses the race the invocation of apt (e.g. use of "packages:" in the config) will fail. There is a lot of discussion online about this change to apt-daily (e.g. unattended upgrades happening during business hours, delaying boot, etc.) and discussion of potential systemd changes regarding timers firing during boot (c.f. https://github.com/systemd/systemd/issues/5659). While it would be better to solve this in apt itself, I suggest that cloud-init be defensive when calling apt and implement some retry mechanism. Various instances of people running into this issue: https://github.com/chef/bento/issues/609 https://clusterhq.atlassian.net/browse/FLOC-4486 https://github.com/boxcutter/ubuntu/issues/73 https://unix.stackexchange.com/questions/315502/how-to-disable-apt-daily-service-on-ubuntu-cloud-vm-image To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1693361/+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 1693361] Re: cloud-init sometimes fails on dpkg lock due to concurrent apt-daily.service execution
** Also affects: cloud-init (Ubuntu) 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/1693361 Title: cloud-init sometimes fails on dpkg lock due to concurrent apt- daily.service execution Status in cloud-init: New Status in cloud-init package in Ubuntu: New Bug description: apt-daily is now a systemd service rather than being invoked by cron.daily. If one builds a custom AMI it is possible that the apt- daily.timer will fire during boot. This can fire at the same time cloud-init is running and if cloud-init loses the race the invocation of apt (e.g. use of "packages:" in the config) will fail. There is a lot of discussion online about this change to apt-daily (e.g. unattended upgrades happening during business hours, delaying boot, etc.) and discussion of potential systemd changes regarding timers firing during boot (c.f. https://github.com/systemd/systemd/issues/5659). While it would be better to solve this in apt itself, I suggest that cloud-init be defensive when calling apt and implement some retry mechanism. Various instances of people running into this issue: https://github.com/chef/bento/issues/609 https://clusterhq.atlassian.net/browse/FLOC-4486 https://github.com/boxcutter/ubuntu/issues/73 https://unix.stackexchange.com/questions/315502/how-to-disable-apt-daily-service-on-ubuntu-cloud-vm-image To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1693361/+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 1646604] [NEW] event posting fails for check-cahce and init-local
Public bug reported: maas 2.1.2+bzr-0ubuntu1~16.04.1 cloud-init 0.7.8-49-g9e904bb-0ubuntu1~16.04.1 when I boot a xenial node with cloud-init, I get these 4 failure post backs: Dec 1 07:16:53 bohr [CLOUDINIT] handlers.py[WARNING]: failed posting event: start: init-local/check-cache: attempting to read from cache [trust] Dec 1 07:16:53 bohr [CLOUDINIT] handlers.py[WARNING]: failed posting event: finish: init-local/check-cache: SUCCESS: no cache found Dec 1 07:16:53 bohr [CLOUDINIT] handlers.py[WARNING]: failed posting event: finish: init-local: SUCCESS: searching for local datasources Dec 1 07:16:53 bohr [CLOUDINIT] handlers.py[WARNING]: failed posting event: start: init-network/check-cache: attempting to read from cache [trust] I'd expect them to work and run cleanly. paste of cloud-init log file: http://paste.ubuntu.com/23564700/ Node deploys successfully, so this is not a major issue for us, but seems like noise that should be fix. ** Affects: cloud-init Importance: Undecided Status: New ** Tags: landscape -- 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/1646604 Title: event posting fails for check-cahce and init-local Status in cloud-init: New Bug description: maas 2.1.2+bzr-0ubuntu1~16.04.1 cloud-init 0.7.8-49-g9e904bb-0ubuntu1~16.04.1 when I boot a xenial node with cloud-init, I get these 4 failure post backs: Dec 1 07:16:53 bohr [CLOUDINIT] handlers.py[WARNING]: failed posting event: start: init-local/check-cache: attempting to read from cache [trust] Dec 1 07:16:53 bohr [CLOUDINIT] handlers.py[WARNING]: failed posting event: finish: init-local/check-cache: SUCCESS: no cache found Dec 1 07:16:53 bohr [CLOUDINIT] handlers.py[WARNING]: failed posting event: finish: init-local: SUCCESS: searching for local datasources Dec 1 07:16:53 bohr [CLOUDINIT] handlers.py[WARNING]: failed posting event: start: init-network/check-cache: attempting to read from cache [trust] I'd expect them to work and run cleanly. paste of cloud-init log file: http://paste.ubuntu.com/23564700/ Node deploys successfully, so this is not a major issue for us, but seems like noise that should be fix. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1646604/+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 1646571] [NEW] apt failures non fatal, but cloud the log
Public bug reported: Better formatting: http://paste.ubuntu.com/23564366/ Dec 01 17:29:15 kepler cloud-init[1134]: 2016-12-01 17:29:15,900 - util.py[WARNING]: Running module apt-configure () failed Dec 01 17:29:15 kepler cloud-init[1134]: [CLOUDINIT] util.py[WARNING]: Running module apt-configure () failed Dec 01 17:29:15 kepler cloud-init[1134]: [CLOUDINIT] util.py[DEBUG]: Running module apt-configure () failed Traceback (most recent call last): File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 792, in _run_modules freq=freq) File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 70, in run return self._runners.run(name, functor, args, freq, clear_on_fail) File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 199, in run results = functor(*args) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_apt_configure.py", line 284, in handle ocfg = convert_to_v3_apt_format(ocfg) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_apt_configure.py", line 748, in convert_to_v3_apt_format cfg = convert_v2_to_v3_apt_format(cfg) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_apt_configure.py", line 714, in convert_v2_to_v3_apt_format oldkey)) ValueError: Old and New apt format defined with unequal values True vs False @ apt_preserve_sources_list D ** Affects: cloud-init Importance: Undecided Status: New ** Description changed: + Better formatting: http://paste.ubuntu.com/23564366/ + Dec 01 17:29:15 kepler cloud-init[1134]: 2016-12-01 17:29:15,900 - util.py[WARNING]: Running module apt-configure () failed Dec 01 17:29:15 kepler cloud-init[1134]: [CLOUDINIT] util.py[WARNING]: Running module apt-configure () failed Dec 01 17:29:15 kepler cloud-init[1134]: [CLOUDINIT] util.py[DEBUG]: Running module apt-configure () failed - Traceback (most recent call last): -File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 792, in _run_modules - freq=freq) -File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 70, in run - return self._runners.run(name, functor, args, freq, clear_on_fail) -File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 199, in run - results = functor(*args) -File "/usr/lib/python3/dist-packages/cloudinit/config/cc_apt_configure.py", line 284, in handle - ocfg = convert_to_v3_apt_format(ocfg) -File "/usr/lib/python3/dist-packages/cloudinit/config/cc_apt_configure.py", line 748, in convert_to_v3_apt_format - cfg = convert_v2_to_v3_apt_format(cfg) -File "/usr/lib/python3/dist-packages/cloudinit/config/cc_apt_configure.py", line 714, in convert_v2_to_v3_apt_format - oldkey)) - ValueError: Old and New apt format defined with unequal values True vs False @ apt_preserve_sources_list + Traceback (most recent call last): + File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 792, in _run_modules + freq=freq) + File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 70, in run + return self._runners.run(name, functor, args, freq, clear_on_fail) + File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 199, in run + results = functor(*args) + File "/usr/lib/python3/dist-packages/cloudinit/config/cc_apt_configure.py", line 284, in handle + ocfg = convert_to_v3_apt_format(ocfg) + File "/usr/lib/python3/dist-packages/cl
[Yahoo-eng-team] [Bug 1461192] Re: TypeError: execv() arg 2 must contain only strings
** Also affects: nova
Importance: Undecided
Status: New
** No longer affects: nova
** Also affects: landscape
Importance: Undecided
Status: New
** Also affects: landscape/release-29
Importance: Undecided
Status: New
** Changed in: landscape/release-29
Milestone: None => 15.08
** Changed in: landscape/release-29
Milestone: 15.08 => 15.07
** Changed in: landscape/release-29
Importance: Undecided => High
** Changed in: landscape
Importance: Undecided => High
--
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/1461192
Title:
TypeError: execv() arg 2 must contain only strings
Status in Landscape Server:
New
Status in Landscape Server release-29 series:
New
Status in nova-compute package in Juju Charms Collection:
In Progress
Bug description:
Got this during an HA Autopilot deployment:
2015-06-02 16:15:49 INFO unit.nova-compute/2.juju-log cmd.go:247 ceph:68:
Rendering from template: nova.conf
2015-06-02 16:15:49 INFO unit.nova-compute/2.juju-log cmd.go:247 ceph:68:
Wrote template /etc/nova/nova.conf.
2015-06-02 16:15:49 INFO unit.nova-compute/2.juju-log cmd.go:247 ceph:68:
Libvirt secret changed for uuid 514c9fca-8cbe-11e2-9c52-3bc8c7819472.
2015-06-02 16:15:49 INFO unit.nova-compute/2.juju-log cmd.go:247 ceph:68:
Defining new libvirt secret for uuid 514c9fca-8cbe-11e2-9c52-3bc8c7819472.
2015-06-02 16:15:49 INFO unit.nova-compute/2.ceph-relation-changed
logger.go:40 Secret 514c9fca-8cbe-11e2-9c52-3bc8c7819472 created
2015-06-02 16:15:49 INFO unit.nova-compute/2.ceph-relation-changed
logger.go:40
2015-06-02 16:15:49 INFO unit.nova-compute/2.ceph-relation-changed
logger.go:40 Traceback (most recent call last):
2015-06-02 16:15:49 INFO unit.nova-compute/2.ceph-relation-changed
logger.go:40 File
"/var/lib/juju/agents/unit-nova-compute-2/charm/hooks/ceph-relation-changed",
line
390, in
2015-06-02 16:15:49 INFO unit.nova-compute/2.ceph-relation-changed
logger.go:40 main()
2015-06-02 16:15:49 INFO unit.nova-compute/2.ceph-relation-changed
logger.go:40 File
"/var/lib/juju/agents/unit-nova-compute-2/charm/hooks/ceph-relation-changed",
line
384, in main
2015-06-02 16:15:49 INFO unit.nova-compute/2.ceph-relation-changed
logger.go:40 hooks.execute(sys.argv)
2015-06-02 16:15:49 INFO unit.nova-compute/2.ceph-relation-changed
logger.go:40 File
"/var/lib/juju/agents/unit-nova-compute-2/charm/hooks/charmhelpers/core/hookenv.py
", line 557, in execute
2015-06-02 16:15:49 INFO unit.nova-compute/2.ceph-relation-changed
logger.go:40 self._hooks[hook_name]()
2015-06-02 16:15:49 INFO unit.nova-compute/2.ceph-relation-changed
logger.go:40 File
"/var/lib/juju/agents/unit-nova-compute-2/charm/hooks/charmhelpers/core/host.py",
line 312, in wrapped_f
2015-06-02 16:15:49 INFO unit.nova-compute/2.ceph-relation-changed
logger.go:40 f(*args, **kwargs)
2015-06-02 16:15:49 INFO unit.nova-compute/2.ceph-relation-changed
logger.go:40 File
"/var/lib/juju/agents/unit-nova-compute-2/charm/hooks/ceph-relation-changed",
line
284, in ceph_changed
2015-06-02 16:15:49 INFO unit.nova-compute/2.ceph-relation-changed
logger.go:40 key=relation_get('key'))
2015-06-02 16:15:49 INFO unit.nova-compute/2.ceph-relation-changed
logger.go:40 File
"/var/lib/juju/agents/unit-nova-compute-2/charm/hooks/nova_compute_utils.py",
line
564, in create_libvirt_secret
2015-06-02 16:15:49 INFO unit.nova-compute/2.ceph-relation-changed
logger.go:40 check_call(cmd)
2015-06-02 16:15:49 INFO unit.nova-compute/2.ceph-relation-changed
logger.go:40 File "/usr/lib/python2.7/subprocess.py", line 535, in check_call
2015-06-02 16:15:49 INFO unit.nova-compute/2.ceph-relation-changed
logger.go:40 retcode = call(*popenargs, **kwargs)
2015-06-02 16:15:49 INFO unit.nova-compute/2.ceph-relation-changed
logger.go:40 File "/usr/lib/python2.7/subprocess.py", line 522, in call
2015-06-02 16:15:49 INFO unit.nova-compute/2.ceph-relation-changed
logger.go:40 return Popen(*popenargs, **kwargs).wait()
2015-06-02 16:15:49 INFO unit.nova-compute/2.ceph-relation-changed
logger.go:40 File "/usr/lib/python2.7/subprocess.py", line 710, in __init__
2015-06-02 16:15:49 INFO unit.nova-compute/2.ceph-relation-changed
logger.go:40 errread, errwrite)
2015-06-02 16:15:49 INFO unit.nova-compute/2.ceph-relation-changed
logger.go:40 File "/usr/lib/python2.7/subprocess.py", line 1327, in
_execute_child
2015-06-02 16:15:49 INFO unit.nova-compute/2.ceph-relation-changed
logger.go:40 raise child_exception
2015-06-02 16:15:49 INFO unit.nova-compute/2.ceph-relation-changed
logger.go:40 TypeError: execv() arg 2 must contain only strings
2015-06-02 16:15:49 ERROR juju.worker.uniter.operation runhook.go:86 hook
"ceph-relation-changed" failed: exit status 1
That's:
[Yahoo-eng-team] [Bug 1454410] [NEW] Juno HA Deployment, percona on VIP, killed leader, compute did not reconnect
Public bug reported: ii nova-common1:2014.2.2-0ubuntu1~cloud0 all OpenStack Compute - common files ii nova-compute 1:2014.2.2-0ubuntu1~cloud0 all OpenStack Compute - compute node base ii nova-compute-kvm 1:2014.2.2-0ubuntu1~cloud0 all OpenStack Compute - compute node (KVM) I have a 14 compute node deployment, my VIP percona leader was axed and one of the compute services did not reconnect. 13 did, so clearly there is retry logic already involved that is working in most cases. Will attach full stack trace, The missing log entry that all the good units have seems to be this: 2015-05-12 19:55:52.867 229965 ERROR nova.servicegroup.drivers.db [-] Recovered model server connection! ** Affects: nova Importance: Undecided Status: New ** Tags: cloud-installer landscape -- 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/1454410 Title: Juno HA Deployment, percona on VIP, killed leader, compute did not reconnect Status in OpenStack Compute (Nova): New Bug description: ii nova-common1:2014.2.2-0ubuntu1~cloud0 all OpenStack Compute - common files ii nova-compute 1:2014.2.2-0ubuntu1~cloud0 all OpenStack Compute - compute node base ii nova-compute-kvm 1:2014.2.2-0ubuntu1~cloud0 all OpenStack Compute - compute node (KVM) I have a 14 compute node deployment, my VIP percona leader was axed and one of the compute services did not reconnect. 13 did, so clearly there is retry logic already involved that is working in most cases. Will attach full stack trace, The missing log entry that all the good units have seems to be this: 2015-05-12 19:55:52.867 229965 ERROR nova.servicegroup.drivers.db [-] Recovered model server connection! To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1454410/+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 1438520] Re: cloud-init on vivid upgrade causes sigterm, which aborts 'runcmd' execution
** Also affects: juju-core Importance: Undecided Status: New ** No longer affects: juju-core -- 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/1438520 Title: cloud-init on vivid upgrade causes sigterm, which aborts 'runcmd' execution Status in Init scripts for use on cloud images: New Bug description: I used an openstack infrastructure with a vivid beta2 image. End result, if there is cloud-init upgrade available, it installs and abort parts of the cloud-init execution. (bad news for my user scripts!) I'm not sure of all the fallout, but at least my 'runcmd' section was not executed (grep the logs for 'runcmd'). From cloud-init-output.log: Preparing to unpack .../cryptsetup-bin_2%3a1.6.1-1ubuntu7_amd64.deb ...^M Unpacking cryptsetup-bin (2:1.6.1-1ubuntu7) over (2:1.6.1-1ubuntu5) ...^M Preparing to unpack .../cryptsetup_2%3a1.6.1-1ubuntu7_amd64.deb ...^M Unpacking cryptsetup (2:1.6.1-1ubuntu7) over (2:1.6.1-1ubuntu5) ...^M Preparing to unpack .../cloud-init_0.7.7~bzr1087-0ubuntu1_all.deb ...^M Cloud-init v. 0.7.7 running 'modules:final' at Tue, 31 Mar 2015 05:09:42 +. Up 848.15 seconds. Cloud-init v. 0.7.7 finished at Tue, 31 Mar 2015 05:09:44 +. Datasource DataSourceOpenStack [net,ver=2]. Up 850.19 seconds From cloud-init.log: Mar 31 04:57:38 ubuntu [CLOUDINIT] util.py[DEBUG]: Running command ['eatmydata', 'apt-get', '--option=Dpkg::Options::=--force-confold', '--option=Dpkg::options::=--force-unsafe-io', '--assume-yes', '--quiet', 'dist-upgrade'] with allowed return codes [0] (shell=False, capture=False) Mar 31 05:09:41 ubuntu [CLOUDINIT] util.py[DEBUG]: Cloud-init 0.7.7 received SIGTERM, exiting...#012 Filename: /usr/lib/python3.4/subprocess.py#012 Function: _eintr_retry_call#012 Line number: 491#012Filename: /usr/lib/python3.4/subprocess.py#012Function: _try_wait#012Line number: 1514#012 Filename: /usr/lib/python3.4/subprocess.py#012 Function: wait#012 Line number: 1566 Mar 31 05:09:41 ubuntu [CLOUDINIT] util.py[DEBUG]: apt-upgrade [eatmydata apt-get --option=Dpkg::Options::=--force-confold --option=Dpkg::options::=--force-unsafe-io --assume-yes --quiet dist-upgrade] took 722.766 seconds Mar 31 05:09:41 ubuntu [CLOUDINIT] util.py[DEBUG]: Reading from /proc/uptime (quiet=False) Mar 31 05:09:41 ubuntu [CLOUDINIT] util.py[DEBUG]: Read 12 bytes from /proc/uptime Mar 31 05:09:41 ubuntu [CLOUDINIT] util.py[DEBUG]: cloud-init mode 'modules' took 761.227 seconds (761.23) Mar 31 05:09:42 ubuntu [CLOUDINIT] util.py[DEBUG]: Cloud-init v. 0.7.7 running 'modules:final' at Tue, 31 Mar 2015 05:09:42 +. Up 848.15 seconds. Mar 31 05:09:44 ubuntu [CLOUDINIT] stages.py[DEBUG]: Using distro class Mar 31 05:09:44 ubuntu [CLOUDINIT] stages.py[DEBUG]: Running module rightscale_userdata () with frequency once-per-instance I'll attach full cloud-init logs and the userdata. I used the following command to boot the instance: nova boot --key-name dpb --user-data ~/test.txt --image fc7aedfd-f465-48b9-9fc6-c826f3a0e81b --flavor 2 vivid-test and the image is this: ubuntu-released/ubuntu- vivid-15.04-beta2-amd64-server-20150325-disk1.img To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1438520/+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 1438520] [NEW] cloud-init on vivid upgrade causes sigterm, which aborts 'runcmd' execution
Public bug reported: I used an openstack infrastructure with a vivid beta2 image. End result, if there is cloud-init upgrade available, it installs and abort parts of the cloud-init execution. (bad news for my user scripts!) I'm not sure of all the fallout, but at least my 'runcmd' section was not executed (grep the logs for 'runcmd'). >From cloud-init-output.log: Preparing to unpack .../cryptsetup-bin_2%3a1.6.1-1ubuntu7_amd64.deb ...^M Unpacking cryptsetup-bin (2:1.6.1-1ubuntu7) over (2:1.6.1-1ubuntu5) ...^M Preparing to unpack .../cryptsetup_2%3a1.6.1-1ubuntu7_amd64.deb ...^M Unpacking cryptsetup (2:1.6.1-1ubuntu7) over (2:1.6.1-1ubuntu5) ...^M Preparing to unpack .../cloud-init_0.7.7~bzr1087-0ubuntu1_all.deb ...^M Cloud-init v. 0.7.7 running 'modules:final' at Tue, 31 Mar 2015 05:09:42 +. Up 848.15 seconds. Cloud-init v. 0.7.7 finished at Tue, 31 Mar 2015 05:09:44 +. Datasource DataSourceOpenStack [net,ver=2]. Up 850.19 seconds >From cloud-init.log: Mar 31 04:57:38 ubuntu [CLOUDINIT] util.py[DEBUG]: Running command ['eatmydata', 'apt-get', '--option=Dpkg::Options::=--force-confold', '--option=Dpkg::options::=--force-unsafe-io', '--assume-yes', '--quiet', 'dist-upgrade'] with allowed return codes [0] (shell=False, capture=False) Mar 31 05:09:41 ubuntu [CLOUDINIT] util.py[DEBUG]: Cloud-init 0.7.7 received SIGTERM, exiting...#012 Filename: /usr/lib/python3.4/subprocess.py#012 Function: _eintr_retry_call#012 Line number: 491#012Filename: /usr/lib/python3.4/subprocess.py#012Function: _try_wait#012Line number: 1514#012 Filename: /usr/lib/python3.4/subprocess.py#012 Function: wait#012 Line number: 1566 Mar 31 05:09:41 ubuntu [CLOUDINIT] util.py[DEBUG]: apt-upgrade [eatmydata apt-get --option=Dpkg::Options::=--force-confold --option=Dpkg::options::=--force-unsafe-io --assume-yes --quiet dist-upgrade] took 722.766 seconds Mar 31 05:09:41 ubuntu [CLOUDINIT] util.py[DEBUG]: Reading from /proc/uptime (quiet=False) Mar 31 05:09:41 ubuntu [CLOUDINIT] util.py[DEBUG]: Read 12 bytes from /proc/uptime Mar 31 05:09:41 ubuntu [CLOUDINIT] util.py[DEBUG]: cloud-init mode 'modules' took 761.227 seconds (761.23) Mar 31 05:09:42 ubuntu [CLOUDINIT] util.py[DEBUG]: Cloud-init v. 0.7.7 running 'modules:final' at Tue, 31 Mar 2015 05:09:42 +. Up 848.15 seconds. Mar 31 05:09:44 ubuntu [CLOUDINIT] stages.py[DEBUG]: Using distro class Mar 31 05:09:44 ubuntu [CLOUDINIT] stages.py[DEBUG]: Running module rightscale_userdata () with frequency once-per-instance I'll attach full cloud-init logs and the userdata. I used the following command to boot the instance: nova boot --key-name dpb --user-data ~/test.txt --image fc7aedfd-f465-48b9-9fc6-c826f3a0e81b --flavor 2 vivid-test and the image is this: ubuntu-released/ubuntu-vivid-15.04-beta2-amd64-server-20150325-disk1.img ** Affects: cloud-init Importance: Undecided Status: New ** Tags: landscape -- 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/1438520 Title: cloud-init on vivid upgrade causes sigterm, which aborts 'runcmd' execution Status in Init scripts for use on cloud images: New Bug description: I used an openstack infrastructure with a vivid beta2 image. End result, if there is cloud-init upgrade available, it installs and abort parts of the cloud-init execution. (bad news for my user scripts!) I'm not sure of all the fallout, but at least my 'runcmd' section was not executed (grep the logs for 'runcmd'). From cloud-init-output.log: Preparing to unpack .../cryptsetup-bin_2%3a1.6.1-1ubuntu7_amd64.deb ...^M Unpacking cryptsetup-bin (2:1.6.1-1ubuntu7) over (2:1.6.1-1ubuntu5) ...^M Preparing to unpack .../cryptsetup_2%3a1.6.1-1ubuntu7_amd64.deb ...^M Unpacking cryptsetup (2:1.6.1-1ubuntu7) over (2:1.6.1-1ubuntu5) ...^M Preparing to unpack .../cloud-init_0.7.7~bzr1087-0ubuntu1_all.deb ...^M Cloud-init v. 0.7.7 running 'modules:final' at Tue, 31 Mar 2015 05:09:42 +. Up 848.15 seconds. Cloud-init v. 0.7.7 finished at Tue, 31 Mar 2015 05:09:44 +. Datasource DataSourceOpenStack [net,ver=2]. Up 850.19 seconds From cloud-init.log: Mar 31 04:57:38 ubuntu [CLOUDINIT] util.py[DEBUG]: Running command ['eatmydata', 'apt-get', '--option=Dpkg::Options::=--force-confold', '--option=Dpkg::options::=--force-unsafe-io', '--assume-yes', '--quiet', 'dist-upgrade'] with allowed return codes [0] (shell=False, capture=False) Mar 31 05:09:41 ubuntu [CLOUDINIT] util.py[DEBUG]: Cloud-init 0.7.7 received SIGTERM, exiting...#012 Filename: /usr/lib/python3.4/subprocess.py#012 Function: _eintr_retry_call#012 Line number: 491#012Filename: /usr/lib/python3.4/subprocess.py#012Function: _try_wait#012Line number: 1514#012 Filename: /usr/lib/python3.4/subprocess.py#012 Function: wait#012 Line number: 1566 Mar 31 05:09:41 ubuntu
[Yahoo-eng-team] [Bug 1353008] Re: MAAS Provider: LXC did not get DHCP address, stuck in "pending"
** 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/1353008 Title: MAAS Provider: LXC did not get DHCP address, stuck in "pending" Status in Init scripts for use on cloud images: New Status in juju-core: Triaged Status in juju-core 1.20 series: Triaged Bug description: Note, that after I went onto the system, it *did* have an IP address. 0/lxc/3: agent-state: pending instance-id: juju-machine-0-lxc-3 series: trusty hardware: arch=amd64 cloud-init-output.log snip: Cloud-init v. 0.7.5 running 'init' at Mon, 04 Aug 2014 23:57:12 +. Up 572.29 seconds. ci-info: +++Net device info+++ ci-info: ++--+---+---+---+ ci-info: | Device | Up | Address |Mask | Hw-Address| ci-info: ++--+---+---+---+ ci-info: | lo | True | 127.0.0.1 | 255.0.0.0 | . | ci-info: | eth0 | True | . | . | 00:16:3e:34:aa:57 | ci-info: ++--+---+---+---+ ci-info: !!!Route info failed Cloud-init v. 0.7.5 running 'modules:config' at Mon, 04 Aug 2014 23:57:12 +. Up 572.99 seconds. Cloud-init v. 0.7.5 running 'modules:final' at Mon, 04 Aug 2014 23:57:14 +. Up 574.42 seconds. Cloud-init v. 0.7.5 finished at Mon, 04 Aug 2014 23:57:14 +. Datasource DataSourceNoCloudNet [seed=/var/lib/cloud/seed/nocloud-net][dsmode=net]. Up 574.54 seconds syslog on system, showing DHCPACK 1 second later: root@juju-machine-0-lxc-3:/home/ubuntu# grep DHCP /var/log/syslog Aug 4 23:57:13 juju-machine-0-lxc-3 dhclient: DHCPREQUEST of 10.96.3.173 on eth0 to 255.255.255.255 port 67 (xid=0x1687c544) Aug 4 23:57:13 juju-machine-0-lxc-3 dhclient: DHCPOFFER of 10.96.3.173 from 10.96.0.10 Aug 4 23:57:13 juju-machine-0-lxc-3 dhclient: DHCPACK of 10.96.3.173 from 10.96.0.10 Aug 5 05:28:15 juju-machine-0-lxc-3 dhclient: DHCPREQUEST of 10.96.3.173 on eth0 to 10.96.0.10 port 67 (xid=0x1687c544) Aug 5 05:28:15 juju-machine-0-lxc-3 dhclient: DHCPACK of 10.96.3.173 from 10.96.0.10 Aug 5 11:15:00 juju-machine-0-lxc-3 dhclient: DHCPREQUEST of 10.96.3.173 on eth0 to 10.96.0.10 port 67 (xid=0x1687c544) Aug 5 11:15:00 juju-machine-0-lxc-3 dhclient: DHCPACK of 10.96.3.173 from 10.96.0.10 It appears in every case, cloud-init init-local has failed very early visible in juju logs /var/lib/juju/containers//console.log: Traceback (most recent call last): File "/usr/bin/cloud-init", line 618, in sys.exit(main()) File "/usr/bin/cloud-init", line 614, in main get_uptime=True, func=functor, args=(name, args)) File "/usr/lib/python2.7/dist-packages/cloudinit/util.py", line 1875, in log_time ret = func(*args, **kwargs) File "/usr/bin/cloud-init", line 491, in status_wrapper force=True) File "/usr/lib/python2.7/dist-packages/cloudinit/util.py", line 1402, in sym_link os.symlink(source, link) OSError: [Errno 2] No such file or directory To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1353008/+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
