[Kernel-packages] [Bug 1896604] Re: Groovy kernel (5.8.0-1004-aws) creates broken /dev/console on i3.metal instances
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3789 ** Bug watch added: github.com/canonical/cloud-init/issues #3789 https://github.com/canonical/cloud-init/issues/3789 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-aws in Ubuntu. https://bugs.launchpad.net/bugs/1896604 Title: Groovy kernel (5.8.0-1004-aws) creates broken /dev/console on i3.metal instances Status in cloud-images: Fix Released Status in cloud-init: Fix Released Status in linux-aws package in Ubuntu: Fix Released Bug description: [Impact] Starting with kernel 5.8 the default nr_uarts has been changed from 4 to 2 for amd64, but this seems to affect i3.metal instances in AWS, because ttyS0 is now remapped to ttyS4 and this is breaking tools like cloud-init (and probably something else). [Test case] # echo > /dev/console bash: echo: write error: Input/output error [Fix] Setting nr_uarts=4 by default (via CONFIG_SERIAL_8250_RUNTIME_UARTS) restores the previous behavior and writing to /dev/console works without returning any error. [Regression potential] Minimal. Restores the old behavior used in 5.4 (that shouldn't have changed in the first place). [Original bug report] Hi, When running Groovy daily images on i3.metal instances a broken /dev/console is created. The char device appears to be writable but writing to it causes an Input/output error. This is breaking cloud- init, as it tries to log to /dev/console, and is likely to break other programs. On Focal: root@ip-172-31-24-163:~# ls -l /dev/console crw--- 1 root root 5, 1 Sep 21 16:07 /dev/console root@ip-172-31-24-163:~# echo x > /dev/console root@ip-172-31-24-163:~# On Groovy: root@ip-172-31-20-184:~# ls -l /dev/console crw--w 1 root tty 5, 1 Sep 21 16:03 /dev/console root@ip-172-31-20-184:~# echo x > /dev/console bash: echo: write error: Input/output error The Groovy kernel log has a [ 3.561696] fbcon: Taking over console line in it, which is not present in the Focal kernel log (5.4.0-1024-aws). Perhaps fbcon should be prevented from taking over console? To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1896604/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1858615] Re: dmidecode triggers system reboot on Inforce 6640
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3525 ** Bug watch added: github.com/canonical/cloud-init/issues #3525 https://github.com/canonical/cloud-init/issues/3525 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to dmidecode in Ubuntu. https://bugs.launchpad.net/bugs/1858615 Title: dmidecode triggers system reboot on Inforce 6640 Status in cloud-init: Invalid Status in dmidecode package in Ubuntu: Fix Released Status in dmidecode source package in Xenial: Fix Released Status in dmidecode source package in Bionic: Fix Released Status in dmidecode source package in Eoan: Fix Released Status in dmidecode source package in Focal: Fix Released Status in dmidecode package in Debian: Fix Released Bug description: [Impact] Running 'sudo dmidecode' on non-UEFI ARM systems can cause them to crash/reboot. cloud-init apparently runs dmidecode as root, so it breaks any cloud-init based installation. [Test Case] sudo dmidecode [Fix] Upstream has the following fix: commit e12ec26e19e02281d3e7258c3aabb88a5cf5ec1d Author: Jean Delvare Date: Mon Aug 26 14:20:15 2019 +0200 dmidecode: Only scan /dev/mem for entry point on x86 [Regression Risk] In Ubuntu, dmidecode only builds on amd64, arm64, armhf & i386. The fix is to disable code on !x86, so the regression risk is restricted to ARM platforms, where we know /dev/mem trolling is bad news. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1858615/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1803173] Re: cloud-init disables user on azure at second reboot
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3279 ** Bug watch added: github.com/canonical/cloud-init/issues #3279 https://github.com/canonical/cloud-init/issues/3279 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1803173 Title: cloud-init disables user on azure at second reboot Status in cloud-init: Invalid Status in linux package in Ubuntu: Triaged Status in walinuxagent package in Ubuntu: Confirmed Bug description: Hello, Environment: platform: Azure arm image: Canonical UbuntuServer 16.04-DAILY-LTS latest Steps: Deploy VM with user/pass authentication Install latest linux-next-upstream kernel (for example 4.19.0-4db9d11bcbef, where 4db9d11bcbef is the git tag from the linux-next latest tree: https://kernel.googlesource.com/pub/scm/linux/kernel/git/next/linux-next/) reboot (all good) reboot again cloud-init disables the username password authentication I checked the cloud-init logs and found: 2018-11-01 16:45:28,566 - init.py[INFO]: User already exists, skipping. 2018-11-01 16:45:28,570 - util.py[DEBUG]: Running command ['passwd', '-l', ''] with allowed return codes [0] (shell=False, capture=True) 2018-11-01 16:45:28,793 - util.py[DEBUG]: Reading from /etc/sudoers (quiet=False) 2018-11-01 16:45:28,795 - util.py[DEBUG]: Read 781 bytes from /etc/sudoers 2018-11-01 16:45:28,796 - util.py[DEBUG]: Writing to /etc/sudoers.d/90-cloud-init-users - ab: [None] 51 bytes 2018-11-01 16:45:28,797 - handlers.py[DEBUG]: finish: init-network/config-users-groups: SUCCESS: config-users-groups ran successfully This issue is very bad one, as it can render your vm inaccessible on Azure. I think this problem is due to the new kernel installation. Initial bug report: https://github.com/Azure/WALinuxAgent/issues/1386 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1803173/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1778891] Re: KVM Instance booting from volume stacktraces
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3199 ** Bug watch added: github.com/canonical/cloud-init/issues #3199 https://github.com/canonical/cloud-init/issues/3199 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1778891 Title: KVM Instance booting from volume stacktraces Status in cloud-init: Invalid Status in cloud-init package in Ubuntu: Invalid Status in linux package in Ubuntu: Expired Bug description: I've booted two instances from the same backing image (http://cloud- images.ubuntu.com/trusty/current/trusty-server-cloudimg- amd64-disk1.img), one using locally attached storage for the boot volume, one using a Cinder volume. The instance booted from cinder volume shows a cloud-init trace in the console log, while the local instance works correctly. Instance booted from volume: Cloud-init v. 0.7.5 running 'init' at Wed, 27 Jun 2018 09:43:10 +. Up 15.61 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 | 192.168.21.8 | 255.255.255.0 | fa:16:3e:aa:c3:54 | ci-info: ++--+--+---+---+ ci-info: +++Route info+++ ci-info: +---+-+--+-+---+---+ ci-info: | Route | Destination | Gateway| Genmask | Interface | Flags | ci-info: +---+-+--+-+---+---+ ci-info: | 0 | 0.0.0.0 | 192.168.21.1 | 0.0.0.0 |eth0 | UG | ci-info: | 1 | 169.254.169.254 | 192.168.21.1 | 255.255.255.255 |eth0 | UGH | ci-info: | 2 | 192.168.21.0 | 0.0.0.0| 255.255.255.0 |eth0 | U | ci-info: +---+-+--+-+---+---+ dmesg: write failed: Broken pipe 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: c7:fb:76:96:ae:aa:6e:73:b1:28:ea:38:40:fa:34:75 root@20180627093956 The key's randomart image is: +--[ RSA 2048]+ | | | | | | | . . E . | |o . . S o | |o o ... | | + . ..o . |[ 36.260523] general protection fault: [#1] SMP [ 36.260523] Modules linked in: dm_crypt kvm_intel kvm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel serio_raw aesni_intel aes_x86_64 glue_helper lrw gf128mul ablk_helper cryptd psmouse floppy [ 36.260523] CPU: 0 PID: 1 Comm: init Not tainted 3.13.0-151-generic #201-Ubuntu [ 36.260523] Hardware name: OpenStack Foundation OpenStack Nova, BIOS 1.10.2-1ubuntu1~cloud0 04/01/2014 [ 36.260523] task: 88007c088000 ti: 88007c086000 task.ti: 88007c086000 [ 36.260523] RIP: 0010:[] [] switch_mm_irqs_off+0xbb/0x120 [ 36.260523] RSP: 0018:88007c087ee0 EFLAGS: 00010046 [ 36.260523] RAX: 0001 RBX: 880037a54700 RCX: 0049 [ 36.260523] RDX: RSI: 880037a54700 RDI: 880037a54700 [ 36.260523] RBP: 88007c087f00 R08: R09: [ 36.260523] R10: 0001 R11: 88007b666780 R12: 8800378d6700 [ 36.260523] R13: R14: 880037653000 R15: 880037653000 [ 36.260523] FS: 7f81d6e9a840() GS:88007fc0() knlGS: [ 36.260523] CS: 0010 DS: ES: CR0: 80050033 [ 36.260523] CR2: 7ffcc8f0fec0 CR3: 37924000 CR4: 00360670 [ 36.260523] DR0: DR1: DR2: [ 36.260523] DR3: DR6: fffe0ff0 DR7: 0400 [ 36.260523] Stack: [ 36.260523] 8800378d6700 88007fc13b40 880037a54700 [ 36.260523] 88007c087f60 8173c613 88007c088000 00013b40 [ 36.260523] 88007c087fd8 00013b40 88007c088000 7ffcc8f10ae0 [ 36.260523] Call Trace: [ 36.260523] [] __schedule+0x2b3/0x750 [ 36.260523] [] schedule_user+0x2e/0xa0 [ 36.260523] [] sysret_careful+0x14/0x1a [ 36.260523] Code: 24 e0 02 00 00 75 28 5b 41 5c 41 5d 41 5e 5d c3 48 8b 05 a5 58 cb 00 48 c1 e8 33 a8 01 74 d7 31 d2 b8 01 00 00 00 b9 49 00 00 00 <0f> 30 eb c7
[Kernel-packages] [Bug 1727358] Re: cloud-init is slow to complete init on minimized images
Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/3042
** Bug watch added: github.com/canonical/cloud-init/issues #3042
https://github.com/canonical/cloud-init/issues/3042
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-kvm in Ubuntu.
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:
Confirmed
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_ed25519_key.pub.
The key fingerprint is:
SHA256:B6B/1SyUB/TFPfmU1ADIotnD+wjISO5L2JZkWe2lDUA root@cloudimg
The key's randomart image is:
+--[ED25519 256]--+
| .E . o++.o+++|
| + ...++...++|
|o o=o.o.+
[Kernel-packages] [Bug 1701297] Re: NTP reload failure (unable to read library) on overlayfs
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/2936 ** Bug watch added: github.com/canonical/cloud-init/issues #2936 https://github.com/canonical/cloud-init/issues/2936 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. 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: Invalid Status in cloud-init package in Ubuntu: Won't Fix Status in linux package in Ubuntu: Fix Released 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/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1682871] Re: attempts to rename vlans / vlans have addr_assign_type of 0 on kernel 4.4
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/2858 ** Bug watch added: github.com/canonical/cloud-init/issues #2858 https://github.com/canonical/cloud-init/issues/2858 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1682871 Title: attempts to rename vlans / vlans have addr_assign_type of 0 on kernel 4.4 Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Status in linux package in Ubuntu: Fix Released Status in cloud-init source package in Xenial: Fix Released Status in linux source package in Xenial: Fix Released Status in cloud-init source package in Yakkety: Fix Released Status in linux source package in Yakkety: Fix Released Status in cloud-init source package in Zesty: Fix Released Status in linux source package in Zesty: Fix Released Bug description: [Impact] * When vlan interfaces are created, their mac address is copied from the underlying interface, but it is not marked by kernel as stolen. * When underlying interface MAC address is changed, it does not propagate to the vlan interfaces. [Test Case] * Create vlan interface, check the addr_assign_type sysfs attribute, it should be 2, not 0. * Update the base interface mac address, the mac address of the vlan interface should change too. * cloud-init test case wget https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/plain/bin/get-proposed-cloudimg; chmod 755 get-proposed-cloudimg; for release in xenial yakkety zesty; do ./get-proposed-cloudimg $release; MODE=vlan ./btest-launch.sh $release-server-cloudimg-amd64-proposed.img ; # ubuntu/passw0rd python3 -c 'from cloudinit.net import get_interfaces_by_mac; print(get_interfaces_by_mac())'; # results in no runtime error and doesn't report vlan interface name done [Regression Potential] * Userspace may rely on non-propagating MAC addresses, and the fact that vlan mac address type is wrongly stated as non-stolen; however this behaviour will be consistent with 4.7+ kernels. [Other Info] * Please cherrypick 308453aa9156a3b8ee382c0949befb507a32b0c1 into v4.4 kernels commit 308453aa9156a3b8ee382c0949befb507a32b0c1 Author: Mike Manning Date: Fri May 27 17:45:07 2016 +0100 vlan: Propagate MAC address to VLANs The MAC address of the physical interface is only copied to the VLAN when it is first created, resulting in an inconsistency after MAC address changes of only newly created VLANs having an up-to-date MAC. The VLANs should continue inheriting the MAC address of the physical interface until the VLAN MAC address is explicitly set to any value. This allows IPv6 EUI64 addresses for the VLAN to reflect any changes to the MAC of the physical interface and thus for DAD to behave as expected. Signed-off-by: Mike Manning Signed-off-by: David S. Miller * Original bug report When attempting to verify sru for bug 1669860, I found that vlans are not properly filtered out by 'get_interfaces_by_mac'. That means that the bug is still present with vlans. The reason for this is that /sys/class/net//addr_assign_type shows '0' for a vlan on 4.4, but (correctly) shows '2' on 4.8. See https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-net for doc on addr_assign_type. Related bugs: * bug 1669860: cloud-init attempts to rename bonds To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1682871/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1551747] Re: ubuntu-fan causes issues during network configuration
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/2623 ** Bug watch added: github.com/canonical/cloud-init/issues #2623 https://github.com/canonical/cloud-init/issues/2623 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to ubuntu-fan in Ubuntu. https://bugs.launchpad.net/bugs/1551747 Title: ubuntu-fan causes issues during network configuration Status in cloud-init: Invalid Status in Snappy: Invalid Status in ubuntu-fan package in Ubuntu: Fix Released Status in ubuntu-fan source package in Xenial: Fix Released Status in ubuntu-fan source package in Yakkety: Fix Released Bug description: it seems that ubuntu-fan is causing issues with network configuration. On 16.04 daily image: root@localhost:~# snappy list NameDate Version Developer canonical-pi2 2016-02-02 3.0 canonical canonical-pi2-linux 2016-02-03 4.3.0-1006-3 canonical ubuntu-core 2016-02-22 16.04.0-10.armhf canonical I see this when I'm activating a wifi card on a raspberry pi 2. root@localhost:~# ifdown wlan0 ifdown: interface wlan0 not configured root@localhost:~# ifup wlan0 Internet Systems Consortium DHCP Client 4.3.3 Copyright 2004-2015 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Listening on LPF/wlan0/c4:e9:84:17:31:9b Sending on LPF/wlan0/c4:e9:84:17:31:9b Sending on Socket/fallback DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 3 (xid=0x81c0c95e) DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 5 (xid=0x81c0c95e) DHCPREQUEST of 192.168.0.170 on wlan0 to 255.255.255.255 port 67 (xid=0x5ec9c081) DHCPOFFER of 192.168.0.170 from 192.168.0.251 DHCPACK of 192.168.0.170 from 192.168.0.251 RTNETLINK answers: File exists bound to 192.168.0.170 -- renewal in 17145 seconds. run-parts: /etc/network/if-up.d/ubuntu-fan exited with return code 1 Failed to bring up wlan0. === [Impact] Installing ubuntu-fan can trigger error messages when initialising with no fan configuration. [Test Case] As above. [Regression Potential] Low, suppresses errorneous error messages. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1551747/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1499869] Re: maas wily deployment to HP Proliant m400 arm64 server cartridge fails
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/2586 ** Bug watch added: github.com/canonical/cloud-init/issues #2586 https://github.com/canonical/cloud-init/issues/2586 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1499869 Title: maas wily deployment to HP Proliant m400 arm64 server cartridge fails Status in cloud-init: Fix Released Status in curtin: Invalid Status in cloud-init package in Ubuntu: Fix Released Status in linux package in Ubuntu: Fix Released Status in linux source package in Vivid: Fix Released Status in cloud-init source package in Wily: Fix Released Status in linux source package in Wily: Fix Released Bug description: This is the error seen on the console: [ 64.149080] cloud-init[834]: 2015-08-27 15:03:29,289 - util.py[WARNING]: Failed fetching metadata from url http://10.229.32.21/MAAS/metadata/curtin [ 124.513212] cloud-init[834]: 2015-09-24 17:23:10,006 - url_helper.py[WARNING]: Calling 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [2427570/120s]: request error [HTTPConnectionPool(host='169.254.169.254', port=80): Max retries exceeded with url: /2009-04-04/meta-data/instance-id (Caused by ConnectTimeoutError(, 'Connection to 169.254.169.254 timed out. (connect timeout=50.0)'))] [ 124.515570] cloud-init[834]: 2015-09-24 17:23:10,007 - DataSourceEc2.py[CRITICAL]: Giving up on md from ['http://169.254.169.25/2009-04-04/meta-data/instance-id'] after 2427570 seconds [ 124.531624] cloud-init[834]: 2015-09-24 17:23:10,024 - url_helper.py[WARNING]: Calling 'http:///latest/meta-data/instance-id' failed [0/120s]: bad status code [404] This times out eventually and the node is left at the login prompt. I can install wily via netboot without issue and some time back, wily was deployable to this node from MAAS. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1499869/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1701297] Re: NTP reload failure (unable to read library) on overlayfs
** Changed in: cloud-init (Ubuntu) Status: Confirmed => Won't Fix -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. 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: Invalid Status in cloud-init package in Ubuntu: Won't Fix Status in linux package in Ubuntu: Fix Released 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/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1830740] Re: [linux-azure] Delay during boot of some instance sizes
https://github.com/canonical/cloud-init/pull/539 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-azure in Ubuntu. https://bugs.launchpad.net/bugs/1830740 Title: [linux-azure] Delay during boot of some instance sizes Status in linux-azure package in Ubuntu: New Bug description: We are seeing a long delay, about 100s, when booting new E32s_v3 VMs. We don’t see this delay with smaller sized Ubuntu VMs(D2s and NC6 sizes). I attached a screen shot of the boot delay. You can see between 7.022911 and 101.325958 seconds there is no activity. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1830740/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
