[Touch-packages] [Bug 1693361] Re: cloud-init sometimes fails on dpkg lock due to concurrent apt-daily.service execution
Not sure if this helps, but we recently added behavior to wait for an apt lock when doing apt commands. This will be included in our next release: https://github.com/canonical/cloud-init/pull/1034 If there are still remaining issues, please open a new bug rather than commenting here. This bug won't be re-opened. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1693361 Title: cloud-init sometimes fails on dpkg lock due to concurrent apt- daily.service execution Status in APT: Fix Released Status in cloud-init: Fix Released Status in apt package in Ubuntu: Invalid Status in cloud-init package in Ubuntu: Fix Released Status in cloud-init source package in Xenial: Fix Released Status in cloud-init source package in Yakkety: Won't Fix Status in cloud-init source package in Zesty: Fix Released Status in cloud-init source package in Artful: Fix Released Bug description: === Begin SRU Template === [Impact] A cloud-config that contains packages to install (see below) or 'package_upgrade' will run 'apt-get update'. That can sometimes fail as a result of contention with the apt-daily.service that updates that information. Cloud-config showing the problem is just like: $ cat my.yaml #cloud-config packages: ['hello'] [Test Case] lxc-proposed-snapshot is https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/tree/bin/lxc-proposed-snapshot It publishes an image to lxd with proposed enabled and cloud-init upgraded. a.) launch an instance with proposed version of cloud-init and some user-data. This is platform independent. The test case demonstrates lxd. $ printf "%s\n%s\n%s\n" "#cloud-config" "packages: ['hello']" \ "package_upgrade: true" > config.yaml $ release=xenial $ ref=proposed-$release $ ./lxc-proposed-snapshot --proposed --publish $release $ref; b.) start the instance $ name=$release-1693361 $ lxc launch my-xenial "--config=user.user-data=$(cat config.yaml) $ sleep 1 $ lxc exec $name -- tail -f /var/log/cloud-init.log /var/log/cloud-init-output.log # watch this boot. c.) Look for evidence of systemd failure journalctl -o short-precise | grep -i break journalctl -o short-precise | grep -i order [Regression Potential] Regression chance here is low. Its possible that ordering loops could occur. When that does happen, journalctl will mention it. Unfortunately in such cases systemd somewhat randomly picks a service to kil so behavior is somewhat undefined. [Other Info] Upstream commit at https://git.launchpad.net/cloud-init/commit/?id=11121fe4 === End SRU Template === 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/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1959343] Re: deprecation of the Canonical partner archive
** Changed in: cloud-init (Ubuntu) Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python-apt in Ubuntu. https://bugs.launchpad.net/bugs/1959343 Title: deprecation of the Canonical partner archive Status in subiquity: Invalid Status in app-install-data-partner package in Ubuntu: Fix Released Status in cloud-init package in Ubuntu: Fix Committed Status in curtin package in Ubuntu: Invalid Status in livecd-rootfs package in Ubuntu: Fix Released Status in python-apt package in Ubuntu: Fix Released Status in ubiquity package in Ubuntu: In Progress Status in ubuntu-release-upgrader package in Ubuntu: Fix Released Status in ubuntu-unity-meta package in Ubuntu: New Bug description: The Canonical partner archive is no longer being used for publishing new packages, and is empty from Ubuntu 20.10 on. We should stop including it in the default sources.list, and clean up references to it in our codebase. To manage notifications about this bug go to: https://bugs.launchpad.net/subiquity/+bug/1959343/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 994698] Re: cloud-init disables ureadahead even when it might be useful
This bug is no longer relevant ** Changed in: cloud-init (Ubuntu) Status: Triaged => Won't Fix -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ureadahead in Ubuntu. https://bugs.launchpad.net/bugs/994698 Title: cloud-init disables ureadahead even when it might be useful Status in cloud-init package in Ubuntu: Won't Fix Status in ureadahead package in Ubuntu: Confirmed Bug description: Since bug 499520, cloud-init currently disables ureadahead by using a dpkg-divert of /etc/upstart/ureadahead.conf. The reasoning behind this was that: a.) ureadahead was causing OOM on boot small vms (~ 300M) b.) ureadahead inside a VM doesn't generally make any sense. Ureadahead tries to optimize disk reads for ssd or spinning disks. Its methods of determining if the disk of the system is ssd or spinning won't work in a VM. c.) ureadahead is part of ubuntu-minimal task, and we did not want to change that. Recently, though, we've started using cloud-init on real hardware, where ureadahead could be of use. Thus, I'd like to have a better solution. I think ureadahead would ideally disable itself if it found one of the following conditions: 1 small amount of memory (<512 or even 1024M) 2 if it is running in a container 3 no definitive knowledge of the type of disks used (if it thought this might be a VM) Of those options, determining the first 2 are straight forward, and I would think could be done in the upstart job even. I'm not familiar enough with ureadahead to know how easily it would be to determine number 3. Related bugs: * bug 499520: default uec-image requires at least 300 M of RAM to run - m1.small and c1.medium not needed by default To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/994698/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-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 Ubuntu Touch seeded packages, which is subscribed to apparmor 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/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1711428] Re: cloud-init sometimes fails on dpkg lock due to concurrent apt-daily-upgrade.service execution
See https://github.com/canonical/cloud-init/pull/1034 and https://github.com/canonical/cloud-init/pull/1153 ** Changed in: cloud-init Status: Incomplete => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1711428 Title: cloud-init sometimes fails on dpkg lock due to concurrent apt-daily- upgrade.service execution Status in cloud-init: Fix Released Status in apt package in Ubuntu: Expired Bug description: This is the same problem as https://bugs.launchpad.net/cloud- init/+bug/1693361, but with a different APT invoking service. In this case it is apt-daily-upgrade.service. So, I guess add apt-daily-upgrade.service to the Before line in /lib/systemd/system/cloud-final.service along side apt-daily.service. Or wait for an APT fix. Or retry APT commands when executing "packages:" Reporting this to save someone else trouble, but I think we'll be rolling back to Trusty at this point. Hopefully the B LTS will have an alternative to systemd. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1711428/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1997124] Re: Netplan/Systemd/Cloud-init/Dbus Race
** Changed in: cloud-init Assignee: (unassigned) => James Falcon (falcojr) ** Changed in: cloud-init Status: Triaged => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1997124 Title: Netplan/Systemd/Cloud-init/Dbus Race Status in cloud-init: In Progress Status in systemd package in Ubuntu: Confirmed Bug description: Cloud-init is seeing intermittent failures while running `netplan apply`, which appears to be caused by a missing resource at the time of call. The symptom in cloud-init logs looks like: Running ['netplan', 'apply'] resulted in stderr output: Failed to connect system bus: No such file or directory I think that this error[1] is likely caused by cloud-init running netplan apply too early in boot process (before dbus is active). Today I stumbled upon this error which was hit in MAAS[2]. We have also hit it intermittently during tests (we didn't have a reproducer). Realizing that this may not be a cloud-init error, but possibly a dependency bug between dbus/systemd we decided to file this bug for broader visibility to other projects. I will follow up this initial report with some comments from our discussion earlier. [1] https://github.com/canonical/netplan/blob/main/src/dbus.c#L801 [2] https://discourse.maas.io/t/latest-ubuntu-20-04-image-causing-netplan-error/5970 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1997124/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1724623] Re: Update ubuntu cloud info
"I'll leave the cloud-init team to comment, but I actually disagree." Yeah, we already provide that info in a more raw state, and for cloud- init, it won't help to pretty it up or do more parsing. Is there something needed from cloud-init for this to work correctly? ** Changed in: cloud-init (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apport in Ubuntu. https://bugs.launchpad.net/bugs/1724623 Title: Update ubuntu cloud info Status in apport package in Ubuntu: New Status in cloud-init package in Ubuntu: Incomplete Bug description: add_cloud_info() in data/general-hooks/ubuntu.py needs an overhaul. Issues: - Using the presence of cloud-init to flag an image as a cloud image is incorrect now that ubuntu-server includes cloud-init (and ubuntu-core images) - Using the presence of EC2 metadata source is incorrect as many non-EC2 clouds provide EC2 metadata. Thus we have bugs like bug #1722946 that are tagged as an 'ec2-images' bug which are clearly on openstack - Marking all bugs that have cloud-init but no EC2 metadata source as an 'uec-images' bug uses a name that no longer has meaning. Solution: - If cloud-init is present, check for /etc/cloud/build.info to indicate an Ubuntu cloud images, tag as 'cloud-images'. Pull the build_name and serial from that file into the bug comments. - If cloud-init is present, check for the presence of /run/cloud-init/cloud.cfg. Parse this yaml to determine the datasource type. Add the datasource used to the bug comment. I have filed bug #1724626 to ask cloud-init development to surface more information from ds-identify to help ID the cloud so that we can better tag/annotate the bug. There may also be some info we can get to indicate the image ID on more clouds than just AWS. At a minimum I would like to see dsidentify make the EC2 platform it found available for consumers in cloud.cfg. This would allow us to identify AWS EC2 from look-alike datasources so that we can tag a bug as ec2-images for bug really on AWS and add EC2 specific fields to the description/attachments. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1724623/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1997124] Re: Netplan/Systemd/Cloud-init/Dbus Race
** Changed in: cloud-init Status: New => Triaged ** Changed in: cloud-init Importance: Undecided => High -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1997124 Title: Netplan/Systemd/Cloud-init/Dbus Race Status in cloud-init: Triaged Status in systemd package in Ubuntu: New Bug description: Cloud-init is seeing intermittent failures while running `netplan apply`, which appears to be caused by a missing resource at the time of call. The symptom in cloud-init logs looks like: Running ['netplan', 'apply'] resulted in stderr output: Failed to connect system bus: No such file or directory I think that this error[1] is likely caused by cloud-init running netplan apply too early in boot process (before dbus is active). Today I stumbled upon this error which was hit in MAAS[2]. We have also hit it intermittently during tests (we didn't have a reproducer). Realizing that this may not be a cloud-init error, but possibly a dependency bug between dbus/systemd we decided to file this bug for broader visibility to other projects. I will follow up this initial report with some comments from our discussion earlier. [1] https://github.com/canonical/netplan/blob/main/src/dbus.c#L801 [2] https://discourse.maas.io/t/latest-ubuntu-20-04-image-causing-netplan-error/5970 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1997124/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 810044] Re: cloud-init will have race conditions for cloud-config with multiple network adapters
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/2194 ** Bug watch added: github.com/canonical/cloud-init/issues #2194 https://github.com/canonical/cloud-init/issues/2194 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ifupdown in Ubuntu. https://bugs.launchpad.net/bugs/810044 Title: cloud-init will have race conditions for cloud-config with multiple network adapters Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Status in ifupdown package in Ubuntu: Fix Released Bug description: right now, if there are multiple network adapters in a system, cloud- init coudl start running cloud-config jobs before network was really up. That means installing additional packages could be attempted before the network required was up. cloud-config could start as early as the first network coming up. ProblemType: Bug DistroRelease: Ubuntu 11.10 Package: cloud-init 0.6.1-0ubuntu11 ProcVersionSignature: User Name 3.0-3.4-virtual 3.0.0-rc5 Uname: Linux 3.0-3-virtual x86_64 Architecture: amd64 Date: Wed Jul 13 17:46:07 2011 PackageArchitecture: all ProcEnviron: PATH=(custom, user) LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: cloud-init UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/810044/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1015223] Re: cloud-init-nonet main process killed by TERM signal
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/2266 ** Bug watch added: github.com/canonical/cloud-init/issues #2266 https://github.com/canonical/cloud-init/issues/2266 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to upstart in Ubuntu. https://bugs.launchpad.net/bugs/1015223 Title: cloud-init-nonet main process killed by TERM signal Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Status in upstart package in Ubuntu: Confirmed Bug description: it has been reported in maas (and i think i've seen it other places) that the console may include: init: cloud-init-nonet main process (307) killed by TERM signal This message is scary to users, even though it is not fatal or even an indication of a problem. It occurs because the cloud-init-nonet's purpose in life is to block the running of cloud-init until the network devices are up. when upstart recognizes that 'static-network-up' it kills cloud-init-nonet, which allows cloud-init to start. ProblemType: Bug DistroRelease: Ubuntu 12.04 Package: cloud-init 0.6.3-0ubuntu1 ProcVersionSignature: User Name 3.2.0-25.40-virtual 3.2.18 Uname: Linux 3.2.0-25-virtual x86_64 ApportVersion: 2.0.1-0ubuntu8 Architecture: amd64 Date: Tue Jun 19 17:41:24 2012 Ec2AMI: ami-b2288bdb Ec2AMIManifest: ubuntu-us-east-1/images-testing/ubuntu-precise-daily-amd64-server-20120616.manifest.xml Ec2AvailabilityZone: us-east-1c Ec2InstanceType: m1.small Ec2Kernel: aki-825ea7eb Ec2Ramdisk: unavailable PackageArchitecture: all ProcEnviron: TERM=screen-bce LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: cloud-init UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1015223/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1359590] Re: Getty's on serial consoles need to be consistent
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/2477 ** Bug watch added: github.com/canonical/cloud-init/issues #2477 https://github.com/canonical/cloud-init/issues/2477 ** Changed in: cloud-init Status: Confirmed => Expired -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1359590 Title: Getty's on serial consoles need to be consistent Status in cloud-init: Expired Status in util-linux package in Ubuntu: Confirmed Bug description: In our cloud images today we launch a getty on ttyS0, as long as it's not in a container. We don't launch a getty on ttyS1-n even if they exist. In MAAS, which also uses cloud images, it would often be useful to put getty's on the serial port that is mapped to remote serial access, such as IPMI SOL. It is however difficult to know which is the correct getty. Broadly speaking I think we should have a consistent approach to getty's. That might mean: * launch a getty on each ttySn that passes an stty test (as per ttyS0 currently) * allow cloud-init to prevent some of those, via vendordata or userdata or default behaviour per-cloud or * launch no getty's on ttyS, but * allow cloud-init to create them based on vendordata or userdata or default behaviour per-cloud To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1359590/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1573095] Re: Cloud images fail to boot when a serial port is not available
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/2657 ** Bug watch added: github.com/canonical/cloud-init/issues #2657 https://github.com/canonical/cloud-init/issues/2657 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1573095 Title: Cloud images fail to boot when a serial port is not available Status in cloud-images: Invalid Status in cloud-init: Invalid Status in Ubuntu: Invalid Status in initramfs-tools package in Ubuntu: Fix Released Bug description: I tried to launch a ubuntu 16.04 cloud image within KVM. The image is not booting up and hangs at "Btrfs loaded" Hypervisor env is Proxmox 4.1 [racb: see comment 40 for minimal steps to reproduce using Ubuntu- provided tooling only] Related bugs: * bug 1016695: add console=tty1 to cloud-image kernel boot parameters * bug 1123220: cloud-image VM causes kernel panic if image is resized * bug 1061977: Machine fails to commission when console=ttyS0 is present on kernel opts * bug 1573095: Cloud images fail to boot when a serial port is not available * bug 1122245: booting from a cloud image hangs until virsh console is used To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1573095/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1576692] Re: fully support package installation in systemd
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/2662 ** Bug watch added: github.com/canonical/cloud-init/issues #2662 https://github.com/canonical/cloud-init/issues/2662 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to init-system-helpers in Ubuntu. https://bugs.launchpad.net/bugs/1576692 Title: fully support package installation in systemd Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Status in init-system-helpers package in Ubuntu: Fix Released Status in cloud-init source package in Xenial: Fix Released Status in init-system-helpers source package in Xenial: Fix Released Bug description: in cloud-init users can install packages via cloud-config: #cloud-config packages: [apache2] Due to some intricacies of systemd and service installation that doesn't work all that well. We fixed the issue for simple services that do not have any dependencies on other services, or at least don't check those dependencies well under bug 1575572. We'd like to have a way to fully support this in cloud-init. Related bugs: * bug 1575572: apache2 fails to start if installed via cloud config (on Xenial) * bug 1611973: postgresql@9.5-main service not started if postgres installed via cloud-init * bug 1621336: snapd.boot-ok.service hangs eternally on cloud image upgrades (snapd packaging bug, but this cloud-init fix will workaround it) * bug 1620780: dev-sda2.device job running and times out * bug 1623570: Azure: cannot start walinux agent (Transaction order is cyclic.) * bug 1623868: cloud-final.service does not run due to dependency cycle * bug 1627436: [gce] Startup scripts do not run on 1604 images * bug 1624596: [azure] ephemeral-disk-warning.service causes ordering cycle on multi-user.target SRU INFORMATION === FIX for init-system-helpers: https://anonscm.debian.org/cgit/collab-maint/init-system-helpers.git/commit/?id=1460d6a02 REGRESSION POTENTIAL for init-system-helpers: This changes invoke-rc.d and service, two very central pieces of packaging infrastructure. Errors in it will break installation/upgrades of packages or /etc/network/if-up.d/ hooks and the like. This changes the condition when systemd units get started without their dependencies, and the condition gets weakened. This means that behaviour in a booted system is unchanged, but during boot this could change the behaviour of if- up.d/ hooks (although they have never been defined well during boot anyway). However, I tested this change extensively in cloud images and desktop installations (particularly I recreated https://bugs.debian.org/777113 and confirmed that this approach also fixes it) and could not find any regression. TEST CASE (for both packages): Run lxc launch ubuntu-daily:x --config=user.user-data="$(printf "#cloud-config\npackages: [postgresql, samba, postfix]")" x1 This will install all three packages, but "systemctl status postgresql@9.5-main" will not be running. Now prepare a new image with the proposed cloud-init and init-system- helpers: lxc launch ubuntu-daily:x xprep lxc exec xprep bash # enable -proposed and dist-upgrade, then poweroff lxc publish xprep x-proposed Now run the initial lxc launch again, but against that new x-proposed image instead of the standard daily: lxc launch x-proposed --config=user.user-data="$(printf "#cloud- config\npackages: [postgresql, samba, postfix]")" x1 You should now have "systemctl status postgresql@9.5-main" running. Directly after rebooting the instance, check that there are no hanging jobs (systemctl list-jobs), particularly networking.service, to ensure that https://bugs.debian.org/777113 did not come back. Also test interactively installing a package that ships a service, like "apache2", and verify that it starts properly after installation. Verify that journalctl shows no dependency cycles and that all cloud init services and the target are active: $ systemctl list-units --no-legend --all 'cloud*' cloud-config.service loaded active exited Apply the settings specified in cloud-config cloud-final.service loaded active exited Execute cloud user/final scripts cloud-init-local.service loaded active exited Initial cloud-init job (pre-networking) cloud-init.service loaded active exited Initial cloud-init job (metadata service crawler) cloud-config.target loaded active active Cloud-config availability cloud-init.targetloaded active active Cloud-init target To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1576692/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help :
[Touch-packages] [Bug 1629797] Re: resolve service in nsswitch.conf adds 25 seconds to failed lookups before systemd-resolved is up
Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2737
** Bug watch added: github.com/canonical/cloud-init/issues #2737
https://github.com/canonical/cloud-init/issues/2737
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dbus in Ubuntu.
https://bugs.launchpad.net/bugs/1629797
Title:
resolve service in nsswitch.conf adds 25 seconds to failed lookups
before systemd-resolved is up
Status in cloud-init:
Fix Released
Status in D-Bus:
Unknown
Status in cloud-init package in Ubuntu:
Fix Released
Status in dbus package in Ubuntu:
Won't Fix
Status in cloud-init source package in Xenial:
Confirmed
Status in cloud-init source package in Yakkety:
Fix Released
Bug description:
=== Begin SRU Template ===
[Impact]
In cases where cloud-init used dns during early boot and system was
configured in nsswitch.conf to use systemd-resolvd, the system would
timeout on dns attempts making system boot terribly slow.
[Test Case]
Boot a system on GCE.
check for WARN in /var/log/messages
check that time to boot is reasonable (<30 seconds). In failure case the
times would be minutes.
[Regression Potential]
Changing order in boot can be dangerous. There is real chance for
regression here, but it should be fairly small as xenial does not include
systemd-resolved usage. This was first noticed on yakkety where it did.
[Other Info]
It seems useful to SRU this in the event that systemd-resolvd is used
on 16.04 or the case where user upgrades components (admittedly small use
case).
=== End SRU Template ===
During boot, cloud-init does DNS resolution checks to if particular metadata
services are available (in order to determine which cloud it is running on).
These checks happen before systemd-resolved is up[0] and if they resolve
unsuccessfully they take 25 seconds to complete.
This has substantial impact on boot time in all contexts, because
cloud-init attempts to resolve three known-invalid addresses ("does-
not-exist.example.com.", "example.invalid." and a random string) to
enable it to detect when it's running in an environment where a DNS
server will always return some sort of redirect. As such, we're
talking a minimum impact of 75 seconds in all environments. This
increases when cloud-init is configured to check for multiple
environments.
This means that yakkety is consistently taking 2-3 minutes to boot on
EC2 and GCE, compared to the ~30 seconds of the first boot and ~10
seconds thereafter in xenial.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1629797/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1707222] Re: usage of /tmp during boot is not safe due to systemd-tmpfiles-clean
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/2967 ** Bug watch added: github.com/canonical/cloud-init/issues #2967 https://github.com/canonical/cloud-init/issues/2967 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1707222 Title: usage of /tmp during boot is not safe due to systemd-tmpfiles-clean Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Won't Fix Bug description: Earlier this week on Zesty on Azure I saw a cloud-init failure in its 'mount_cb' function. That function esentially does: a.) make a tmp directory for a mount point b.) mount some filesystem to that mount point c.) call a function d.) unmount the directory What I recall was that access to a file inside the mount point failed during 'c'. This seems possible as systemd-tmpfiles-clean may be running at the same time as cloud-init (cloud-init.service in this example). It seems that this service basically inhibits *any* other service from using tmp files. It's ordering statements are only: After=local-fs.target time-sync.target Before=shutdown.target So while in most cases only services that run early in the boot process like cloud-init will be affected, any service could have its tmp files removed. this service could take quite a long time to run if /tmp/ had been filled with lots of files in the previous boot. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1707222/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-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 Ubuntu Touch seeded packages, which is subscribed to apparmor 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/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1693361] Re: cloud-init sometimes fails on dpkg lock due to concurrent apt-daily.service execution
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/2908 ** Bug watch added: github.com/canonical/cloud-init/issues #2908 https://github.com/canonical/cloud-init/issues/2908 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1693361 Title: cloud-init sometimes fails on dpkg lock due to concurrent apt- daily.service execution Status in APT: Fix Released Status in cloud-init: Fix Released Status in apt package in Ubuntu: Invalid Status in cloud-init package in Ubuntu: Fix Released Status in cloud-init source package in Xenial: Fix Released Status in cloud-init source package in Yakkety: Won't Fix Status in cloud-init source package in Zesty: Fix Released Status in cloud-init source package in Artful: Fix Released Bug description: === Begin SRU Template === [Impact] A cloud-config that contains packages to install (see below) or 'package_upgrade' will run 'apt-get update'. That can sometimes fail as a result of contention with the apt-daily.service that updates that information. Cloud-config showing the problem is just like: $ cat my.yaml #cloud-config packages: ['hello'] [Test Case] lxc-proposed-snapshot is https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/tree/bin/lxc-proposed-snapshot It publishes an image to lxd with proposed enabled and cloud-init upgraded. a.) launch an instance with proposed version of cloud-init and some user-data. This is platform independent. The test case demonstrates lxd. $ printf "%s\n%s\n%s\n" "#cloud-config" "packages: ['hello']" \ "package_upgrade: true" > config.yaml $ release=xenial $ ref=proposed-$release $ ./lxc-proposed-snapshot --proposed --publish $release $ref; b.) start the instance $ name=$release-1693361 $ lxc launch my-xenial "--config=user.user-data=$(cat config.yaml) $ sleep 1 $ lxc exec $name -- tail -f /var/log/cloud-init.log /var/log/cloud-init-output.log # watch this boot. c.) Look for evidence of systemd failure journalctl -o short-precise | grep -i break journalctl -o short-precise | grep -i order [Regression Potential] Regression chance here is low. Its possible that ordering loops could occur. When that does happen, journalctl will mention it. Unfortunately in such cases systemd somewhat randomly picks a service to kil so behavior is somewhat undefined. [Other Info] Upstream commit at https://git.launchpad.net/cloud-init/commit/?id=11121fe4 === End SRU Template === 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/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1718029] Re: cloudstack and azure datasources broken when using netplan/systemd-networkd
Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/3004
** Bug watch added: github.com/canonical/cloud-init/issues #3004
https://github.com/canonical/cloud-init/issues/3004
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1718029
Title:
cloudstack and azure datasources broken when using netplan/systemd-
networkd
Status in cloud-init:
Fix Released
Status in netplan:
Invalid
Status in cloud-init package in Ubuntu:
Fix Released
Status in nplan package in Ubuntu:
Invalid
Status in systemd package in Ubuntu:
Fix Released
Bug description:
In Ubuntu artful, cloud-init renders network configuration through netplan.
This means that there is no dhclient and thus no /var/lib/dhclient/*.leases.
Azure and CloudStack both are reading those leases file to get useful
information about the platform.
Specifically:
* Azure reads option-245 from the dhclient response to find the IP address
of the metadata service.
* CloudStack reads the 'dhcp-server-identifier' option in the dhclient
response to get the address of the virtual router (metadata service). [1]
In ubuntu this happens to be done with systemd-networkd, so cloud-init
can possibly probably interact over the dbus with systemd-networkd to
get information. However that is less than ideal, as ultimately
cloud-init should not need to know that it systemd-networkd is
involved. It should be hidden via netplan. So there should be an
interface to get current networking configuratoin information from
netplan including dhcp lease response info.
--
[1]
http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/4.8/virtual_machines/user-data.html
ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: cloud-init 0.7.9-280-ge626966e-0ubuntu1
ProcVersionSignature: Ubuntu 4.12.0-11.12-generic 4.12.5
Uname: Linux 4.12.0-11-generic x86_64
ApportVersion: 2.20.7-0ubuntu1
Architecture: amd64
CloudName: Amazon - Ec2
Date: Mon Sep 18 19:56:40 2017
PackageArchitecture: all
ProcEnviron:
TERM=xterm-256color
PATH=(custom, no user)
LANG=C.UTF-8
SourcePackage: cloud-init
UpgradeStatus: No upgrade log present (probably fresh install)
user_data.txt:
#cloud-config
{}
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1718029/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1732522] Re: [2.3] Ephemeral boot environment does not renew DHCP leases
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3057 ** Bug watch added: github.com/canonical/cloud-init/issues #3057 https://github.com/canonical/cloud-init/issues/3057 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1732522 Title: [2.3] Ephemeral boot environment does not renew DHCP leases Status in cloud-init: Invalid Status in MAAS: Fix Released Status in cloud-initramfs-tools package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Invalid Bug description: I started commissioning+hardware testing on a machine, and while the machine was testing (for 2hrs+) i noticed that the IP address had disappeared. The machine has the MAC of 00:25:90:4c:e7:9e and IP of 192.168.0.211 from the dynamic range. Checking the MAAS server, I noticed that the IP/MAC was in the ARP table: andreserl@maas:/var/lib/maas/dhcp$ arp -a | grep 211 192-168-9-211.maas (192.168.9.211) at 00:25:90:4c:e7:9e [ether] on bond-lan Checking the leases file has the following: http://pastebin.ubuntu.com/25969442/ Then I checked a couple areas of MAAS: - Device discovery, the machine wasn't there. - Subnet details page, the machine wasn't there (e.g. as observed) To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1732522/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1734167] Re: DNS doesn't work in no-cloud as launched by ubuntu
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3065 ** Bug watch added: github.com/canonical/cloud-init/issues #3065 https://github.com/canonical/cloud-init/issues/3065 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1734167 Title: DNS doesn't work in no-cloud as launched by ubuntu Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in cloud-init source package in Zesty: Fix Released Status in systemd source package in Zesty: Fix Released Status in cloud-init source package in Artful: Won't Fix Status in systemd source package in Artful: Fix Released Status in systemd source package in Bionic: Fix Released Bug description: [Impact] * resolved does not start early enough in the boot-process preventing DNS resolution to be operational during early boot, for example as required by special early stages of cloud-init, resulting in failure to boot / provision the instance fully. [Test Case] * Boot container or a VM with a nocloud-net data source, and a URL pointing to the datasource as explained below * Observe that boot completes and provisioning is successful * Check that there are no dns-resolution errors in the cloud-init log / boot log [Regression Potential] * starting resolved earlier may prevent it from connecting to dbus, and may require a restart later on when re-triggered over dbus. This is on artful only, as in bionic resolved has gained ability to reconnected to dbus post-start. Backporting that, however, is too large for an SRU as it requires sd-bus changes. [Other Info] * Original bug report. I use no-cloud to test the kernel in CI (I am maintainer of the bcache subsystem), and have been running it successfully under 16.04 cloud images from qemu, using a qemu command that includes: -smbios "type=1,serial=ds=nocloud- net;s=https://raw.githubusercontent.com/mlyle/mlyle/master/cloud- metadata/linuxtst/" As documented here: http://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html Under the new 17.10 cloud images, this doesn't work: the network comes up, but name resolution doesn't work-- /etc/resolv.conf is a symlink to a nonexistent file at this point of the boot and systemd-resolved is not running. When I manually hack /etc/resolv.conf in the cloud image to point to 4.2.2.1 it works fine. I don't know if nameservice not working is by design, but it seems like it should work. The documentation states: "With ds=nocloud-net, the seedfrom value must start with http://, https:// or ftp://; And https is not going to work for a raw IP address. Related bugs: * bug 1734939: #include fails silently. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1734167/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1711428] Re: cloud-init sometimes fails on dpkg lock due to concurrent apt-daily-upgrade.service execution
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/2977 ** Bug watch added: github.com/canonical/cloud-init/issues #2977 https://github.com/canonical/cloud-init/issues/2977 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1711428 Title: cloud-init sometimes fails on dpkg lock due to concurrent apt-daily- upgrade.service execution Status in cloud-init: Fix Released Status in apt package in Ubuntu: Expired Bug description: This is the same problem as https://bugs.launchpad.net/cloud- init/+bug/1693361, but with a different APT invoking service. In this case it is apt-daily-upgrade.service. So, I guess add apt-daily-upgrade.service to the Before line in /lib/systemd/system/cloud-final.service along side apt-daily.service. Or wait for an APT fix. Or retry APT commands when executing "packages:" Reporting this to save someone else trouble, but I think we'll be rolling back to Trusty at this point. Hopefully the B LTS will have an alternative to systemd. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1711428/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1768468] Re: error in ca_certs module
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3168 ** Bug watch added: github.com/canonical/cloud-init/issues #3168 https://github.com/canonical/cloud-init/issues/3168 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ca-certificates in Ubuntu. https://bugs.launchpad.net/bugs/1768468 Title: error in ca_certs module Status in cloud-init: Invalid Status in ca-certificates package in Ubuntu: New Bug description: Hello, I'm using cloud-init in order to customize Nutanix AHV images. I'm using the ca_certs module to upload our private ca chain (root and intermediate) but in the log I found a log that states that - Cloud-init v. 18.2 running 'init-local' at Wed, 02 May 2018 08:54:58 +. Up 6.25 seconds. Updating certificates in /etc/ssl/certs... rehash: skipping cloud-init-ca-certs.pem,it does not contain exactly one certificate or CRL 1 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d... done. - And the certificates are not trusted. Ubuntu version is 18.04. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1768468/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1750780] Re: Race with local file systems can make open-vm-tools fail to start
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3122 ** Bug watch added: github.com/canonical/cloud-init/issues #3122 https://github.com/canonical/cloud-init/issues/3122 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1750780 Title: Race with local file systems can make open-vm-tools fail to start Status in cloud-init: Invalid Status in open-vm-tools package in Ubuntu: Invalid Status in systemd package in Ubuntu: Fix Released Status in open-vm-tools source package in Xenial: Fix Released Status in systemd source package in Xenial: Incomplete Status in open-vm-tools source package in Artful: Fix Released Status in open-vm-tools package in Debian: Fix Released Bug description: Since the change in [1] open-vm-tools-service starts very (very) early. Not so much due to the Before=cloud-init-local.service But much more by DefaultDependencies=no That can trigger an issue that looks like root@ubuntuguest:~# systemctl status -l open-vm-tools.service ● open-vm-tools.service - Service for virtual machines hosted on VMware Loaded: loaded (/lib/systemd/system/open-vm-tools.service; enabled; vendor preset: enabled) Active: failed (Result: resources) As it is right now open-vm-tools can race with the other early start and then fail. In detail one can find a message like: open-vm-tools.service: Failed to run 'start' task: Read-only file system" This is due to privtaeTmp=yes which is also set needing a writable /var/tmp [2] To ensure this works PrivateTmp would have to be removed (not good) or some after dependencies added that make this work reliably. I added After=local-fs.target which made it work for me in 3/3 tests. I' like to have an ack by the cloud-init Team that this does not totally kill the originally intended Before=cloud-init-local.service I think it does not as local-fs can complete before cloud-init-local, then open-vm-tools can initialize and finally cloud-init-local can pick up the data. To summarize: # cloud-init-local # DefaultDependencies=no Wants=network-pre.target After=systemd-remount-fs.service Before=NetworkManager.service Before=network-pre.target Before=shutdown.target Before=sysinit.target Conflicts=shutdown.target RequiresMountsFor=/var/lib/cloud # open-vm-tools # DefaultDependencies=no Before=cloud-init-local.service Proposed is to add to the latter: After=local-fs.target [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859677 [2]: https://github.com/systemd/systemd/issues/5610 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1750780/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1749722] Re: NTP: take into account systemd-timesyncd where present
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3119 ** Bug watch added: github.com/canonical/cloud-init/issues #3119 https://github.com/canonical/cloud-init/issues/3119 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1749722 Title: NTP: take into account systemd-timesyncd where present Status in cloud-init: Fix Released Status in systemd package in Ubuntu: Invalid Bug description: Currently, the NTP module configures ntpd during cloud-init install by installing and configuring ntpd. ntpd competes with systemd-timesyncd on systemd distros like Ubuntu Xenial. Ideally the NTP module should configure systemd-timesyncd where present, falling back to ntpd where not present. This stops two separate daemons (ntpd and systemd-timesyncd) competing with each other to set the time, where systemd-timesyncd (on Ubuntu at least) has an internal hardcoded compiled in timeserver to fall back on if no timeserver is configured (which is bad, but what can you do). The competing timeserver behaviour is invisible when the machine can see the net, but logs this error constantly when the machine cannot see the net: systemd-timesyncd[527]: Timed out waiting for reply from 91.189.94.4:123 (ntp.ubuntu.com). To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1749722/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1997124] Re: Netplan/Systemd/Cloud-init/Dbus Race
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/4044 ** Bug watch added: github.com/canonical/cloud-init/issues #4044 https://github.com/canonical/cloud-init/issues/4044 ** Changed in: cloud-init Status: In Progress => Expired -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1997124 Title: Netplan/Systemd/Cloud-init/Dbus Race Status in cloud-init: Expired Status in netplan: Triaged Status in systemd package in Ubuntu: Confirmed Bug description: Cloud-init is seeing intermittent failures while running `netplan apply`, which appears to be caused by a missing resource at the time of call. The symptom in cloud-init logs looks like: Running ['netplan', 'apply'] resulted in stderr output: Failed to connect system bus: No such file or directory I think that this error[1] is likely caused by cloud-init running netplan apply too early in boot process (before dbus is active). Today I stumbled upon this error which was hit in MAAS[2]. We have also hit it intermittently during tests (we didn't have a reproducer). Realizing that this may not be a cloud-init error, but possibly a dependency bug between dbus/systemd we decided to file this bug for broader visibility to other projects. I will follow up this initial report with some comments from our discussion earlier. [1] https://github.com/canonical/netplan/blob/main/src/dbus.c#L801 [2] https://discourse.maas.io/t/latest-ubuntu-20-04-image-causing-netplan-error/5970 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1997124/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2008952] Re: DNS failure while trying to fetch user-data
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/4085 ** Bug watch added: github.com/canonical/cloud-init/issues #4085 https://github.com/canonical/cloud-init/issues/4085 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2008952 Title: DNS failure while trying to fetch user-data Status in cloud-init: Fix Released Status in netplan: Invalid Status in subiquity: New Status in livecd-rootfs package in Ubuntu: Fix Released Status in systemd package in Ubuntu: New Bug description: In testing netboot + autoinstall of the new ubuntu desktop subiquity based installer for 23.04 I found cloud-init is failing to retrieve user-data because it can't resolved the hostname in the URL. This same configuration does work for 22.04 based subiquity, so seems a regression. From the ipxe config: imgargs vmlinuz initrd=initrd \ ip=dhcp \ iso-url=http://cdimage.ubuntu.com/daily-live/pending/lunar-desktop-amd64.iso \ fsck.mode=skip \ layerfs-path=minimal.standard.live.squashfs \ autoinstall \ 'ds=nocloud-net;s=http://boot.linuxgroove.com/ubuntu/23.04/' \ That fails, but if we replace boot.linuxgroove.com with the IP it works. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/2008952/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1872124] Re: Please integrate ubuntu-drivers --gpgpu into Ubuntu Server
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3649 ** Bug watch added: github.com/canonical/cloud-init/issues #3649 https://github.com/canonical/cloud-init/issues/3649 ** Changed in: cloud-init Status: Incomplete => Expired -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu. https://bugs.launchpad.net/bugs/1872124 Title: Please integrate ubuntu-drivers --gpgpu into Ubuntu Server Status in cloud-init: Expired Status in MAAS: Incomplete Status in subiquity: Fix Released Status in ubuntu-drivers-common package in Ubuntu: New Status in ubuntu-meta package in Ubuntu: New Bug description: Could subiquity provide an option in the UI to install and execute ubuntu-drivers-common on the target? The use case I'm interested in is an "on-rails" installation of Nvidia drivers for servers being installed for deep learning workloads. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1872124/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1867029] Re: Package ifupdown breaks network configuration by cloud-init
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3619 ** Bug watch added: github.com/canonical/cloud-init/issues #3619 https://github.com/canonical/cloud-init/issues/3619 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ifupdown in Ubuntu. https://bugs.launchpad.net/bugs/1867029 Title: Package ifupdown breaks network configuration by cloud-init Status in cloud-init: Fix Released Status in ifupdown package in Ubuntu: New Bug description: It appears the `ifupdown` package breaks networking configuration that cloud-init would normally handle (?) on both providers. The result, if you image an instance with the `ifupdown` package installed, is that the image is not bootable by Azure/AWS. I'm not familiar with how Azure/AWS/etc use cloud-init for network start up however. I'm filing here for now, in case `cloud-init` needs to be more defensive against `ifupdown`. To reproduce with Packer (I confirmed this method): * Add necessary Azure subscription env vars from `ifupdown-bug.json` * `packer build ifupdown-bug.json` * Try to boot an instance with resulting image * Instance will never boot -- more specifically, networking never comes up. See `boot.log` for an example boot To reproduce manually (only a guess, I did not confirm): * Boot 18.04 ubuntu instance * Install ifupdown * Image the instance * Try to boot instance using new image * Instance won't boot I hit this with Packer, creating new images for booting instances in scaling groups -- `ifupdown` is brought in by `salt`. If this is reproducible via manual installation, there could be some backup images/snapshots that are unable to boot though. This appears to be because cloud-init network start up operations are broken by whatever `ifupdown` sysv/systemd scripts perform on boot. With `ifupdown` installed on Azure, `eth0` does not get an IP address, the instance never fully boots according to Azure, and it will enter an error state. On AWS, the instance boots, but network operations like SSH fail. The `boot.log` is from Azure. Eventually `cloud-init` gives an exception (see `exception.log`), but this seems like a secondary issue related to networking being down. I did try to upgrade cloud-init using nightly PPAs (version 20.1 I believe), but no luck. This is on Ubuntu 18.04 instances from Azure marketplace and AWS Canonical AMI, cloud-init version `19.4-33-gbb4131a2-0ubuntu1~18.04.1`. Related: https://github.com/Azure/WALinuxAgent/issues/1612 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1867029/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1851438] Re: cloud-init disk_setup fails to partition disk for Ubuntu18
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3490 ** Bug watch added: github.com/canonical/cloud-init/issues #3490 https://github.com/canonical/cloud-init/issues/3490 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1851438 Title: cloud-init disk_setup fails to partition disk for Ubuntu18 Status in cloud-init: Fix Released Status in util-linux package in Ubuntu: New Status in util-linux source package in Xenial: New Status in util-linux source package in Bionic: New Status in util-linux source package in Eoan: New Status in util-linux source package in Focal: New Bug description: Pasting disk_setup for cloud-config: disk_setup: /dev/xvde: layout: True overwrite: False type: mbr fs_setup: -device: /dev/xvde filesystem: ext4 label: data overwrite: false partition: auto I want to attach and mount a /data disk on the VM using cloud-init so I just want to single partition 100% of the disk. Error while running the sfdisk command for partitioning the disk (please see attached file). OS: Ubuntu18 How I repro-ed it outside cloud-init environment: 1. Open XenCenter, add a new disk, say /dev/xvdc 2. Run `/sbin/sfdisk --Linux --unit=S --force /dev/xvdc` and specify start sector as 0. Because from the cloud-init logs and source code, I figured that it was picking start sector as 0. Save it and see the error. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1851438/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1848617] Re: Installing ifupdown on bionic does not install a /etc/network/interfaces that sources /etc/network/interfaces.d/*
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3475 ** Bug watch added: github.com/canonical/cloud-init/issues #3475 https://github.com/canonical/cloud-init/issues/3475 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ifupdown in Ubuntu. https://bugs.launchpad.net/bugs/1848617 Title: Installing ifupdown on bionic does not install a /etc/network/interfaces that sources /etc/network/interfaces.d/* Status in cloud-init: Invalid Status in ifupdown package in Ubuntu: New Bug description: For the ubuntu1804 template VM of Azure, the file /etc/network/interfaces lacks a line: source /etc/network/interfaces.d/* So the VM can't get configurations under /etc/network/interfaces.d/ After installing ifupdown on the VM, cloud-init will rewrite file /etc/network/interfaces.d/50-cloud-init.cfg rather than /etc/netplan/50-cloud-init.yaml, but /etc/network/interfaces.d/50-cloud-init.cfg won't take effect. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1848617/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1869155] Re: When installing with subiquity, the generated network config uses the macaddress keyword on s390x (where MAC addresses are not necessarily stable across reboots)
Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/3634
** Bug watch added: github.com/canonical/cloud-init/issues #3634
https://github.com/canonical/cloud-init/issues/3634
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1869155
Title:
When installing with subiquity, the generated network config uses the
macaddress keyword on s390x (where MAC addresses are not necessarily
stable across reboots)
Status in cloud-init:
Invalid
Status in subiquity:
Fix Released
Status in Ubuntu on IBM z Systems:
Fix Released
Status in initramfs-tools package in Ubuntu:
Fix Released
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/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1868246] Re: No network after subiquity LPAR installation on s390x with VLAN
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3629 ** Bug watch added: github.com/canonical/cloud-init/issues #3629 https://github.com/canonical/cloud-init/issues/3629 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1868246 Title: No network after subiquity LPAR installation on s390x with VLAN Status in cloud-init: Invalid Status in subiquity: Fix Released Status in Ubuntu on IBM z Systems: Fix Released Status in initramfs-tools package in Ubuntu: Fix Released Bug description: I tried today an subiquity LPAR installation using the latest ISO (March 19) that includes the latest 20.03 subiquity. The installation itself completed fine, but after the post-install reboot the system didn't had a network active - please note that the LPAR is connected to a VLAN. $ ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group defaul t qlen 1000 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 noop state DOWN group default q len 1000 link/ether a2:8d:91:85:12:e3 brd ff:ff:ff:ff:ff:ff 3: enP1p0s0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 82:0c:2d:0c:b8:70 brd ff:ff:ff:ff:ff:ff 4: enP1p0s0d1: mtu 1500 qdisc noop state DOWN group defaul t qlen 1000 link/ether 82:0c:2d:0c:b8:71 brd ff:ff:ff:ff:ff:ff 5: enP2p0s0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 82:0c:2d:0c:b7:00 brd ff:ff:ff:ff:ff:ff 6: enP2p0s0d1: mtu 1500 qdisc noop state DOWN group defaul t qlen 1000 link/ether 82:0c:2d:0c:b7:01 brd ff:ff:ff:ff:ff:ff Wanting to have a look at the netplan config it turned out that there is no yaml file: $ ls -l /etc/netplan/ total 0 Adding one manually and applying it worked fine. So looks like the installer does not properly generate or copy a 01-netcfg.yaml to /etc/netplan. Please see below the entire steps as well as a compressed file with the entire content of /var/log To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1868246/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1856560] Re: ds-identify - stuck in uninterruptible sleep state
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3520 ** Bug watch added: github.com/canonical/cloud-init/issues #3520 https://github.com/canonical/cloud-init/issues/3520 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1856560 Title: ds-identify - stuck in uninterruptible sleep state Status in cloud-init: Invalid Status in util-linux package in Ubuntu: New Bug description: We got recurring issues with the cloud-init/ds-identify process. It spawns sub-processes "blkid -c /dev/null -o export" which gets stuck in the "D" uninterruptible sleep state. The processes cannot be killed, so the only solution is to reboot the affected server. root 3839 0.0 0.0 4760 1840 ? S Dec05 0:00 /bin/sh /usr/lib/cloud-init/ds-identify root 3844 0.0 0.0 11212 2836 ? D Dec05 0:00 \_ blkid -c /dev/null -o export root 6943 0.0 0.0 4760 1880 ? S Dec05 0:00 /bin/sh /usr/lib/cloud-init/ds-identify root 6948 0.0 0.0 11212 2844 ? D Dec05 0:00 \_ blkid -c /dev/null -o export root 6111 0.0 0.0 4760 1916 ? S Dec12 0:00 /bin/sh /usr/lib/cloud-init/ds-identify root 6149 0.0 0.0 11212 2940 ? D Dec12 0:00 \_ blkid -c /dev/null -o export root 8765 0.0 0.3 926528 24968 ? Ssl Dec12 0:12 /usr/lib/snapd/snapd root 9179 0.0 0.0 4760 1892 ? S Dec12 0:00 /bin/sh /usr/lib/cloud-init/ds-identify root 9185 0.0 0.0 11980 3552 ? D Dec12 0:00 \_ blkid -c /dev/null -o export Distributor ID: Ubuntu Description: Ubuntu 18.04.3 LTS Release: 18.04 Codename: bionic 5.0.0-36-generic #39~18.04.1-Ubuntu SMP Tue Nov 12 11:09:50 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1856560/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1675571] Re: Cloud-init update renders secondary addresses to be incompatible with standard tools
Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2842
** Bug watch added: github.com/canonical/cloud-init/issues #2842
https://github.com/canonical/cloud-init/issues/2842
** Changed in: cloud-init
Status: Confirmed => Expired
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to resolvconf in Ubuntu.
https://bugs.launchpad.net/bugs/1675571
Title:
Cloud-init update renders secondary addresses to be incompatible with
standard tools
Status in cloud-init:
Expired
Status in curtin:
Confirmed
Status in cloud-init package in Ubuntu:
Confirmed
Status in resolvconf package in Ubuntu:
New
Status in resolvconf package in Debian:
Won't Fix
Bug description:
The change of how cloud-init renders
/etc/network/interface.d/50-cloud-init.cfg, standard tools no longer work as
expected:
* resolvconf will nullify nameservers
* if* commands ignore secondary addresses
[ORIGINAL REPORT]
Regresion from Bug #1657940.
When provisioning with multiple eth0 addresses, /etc/resolv.conf is
empty:
Consider:
root@tester:~# cat /etc/network/interfaces.d/50-cloud-init.cfg
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# 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}
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 138.197.98.102
dns-nameservers 8.8.8.8 8.8.4.4
gateway 138.197.96.1
netmask 255.255.240.0
# control-alias eth0
iface eth0 inet static
address 10.17.0.11
netmask 255.255.0.0
Which then yields an empty /etc/resolv.conf:
root@tester:/run/resolvconf# cat interface/eth0.inet
root@tester:/run/resolvconf# cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
The problem is that resolvconfg does pattern matching for eth*.inet.
The second definition of eth0 has no nameserver and therefore
overrides the definition.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1675571/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1951586] Re: Need option to specify wifi regulatory domain
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3926 ** Bug watch added: github.com/canonical/cloud-init/issues #3926 https://github.com/canonical/cloud-init/issues/3926 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1951586 Title: Need option to specify wifi regulatory domain Status in cloud-init: Invalid Status in netplan: Fix Released Status in NetworkManager: New Status in netplan.io package in Ubuntu: Fix Released Status in network-manager package in Ubuntu: Incomplete Status in netplan.io source package in Jammy: Triaged Status in network-manager source package in Jammy: Incomplete Status in netplan.io source package in Kinetic: Fix Released Status in network-manager source package in Kinetic: Incomplete Bug description: It would be nice if netplan offered an option to specify the wifi regulatory domain (country code). For devices such as the Raspberry Pi you are currently advertising that users can simply setup Ubuntu Server headless by putting the wifi configuration details in cloudinit/netplan's "network-config" on the FAT partition of the SD card: https://ubuntu.com/tutorials/how-to-install-ubuntu-on-your-raspberry-pi#3-wifi-or-ethernet But an option to set the wifi country code there does not seem to exist, so may not work. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1951586/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1905493] Re: Services (apparmor, snapd.seeded, ...?) fail to start in nested lxd container
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3813 ** Bug watch added: github.com/canonical/cloud-init/issues #3813 https://github.com/canonical/cloud-init/issues/3813 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dbus in Ubuntu. https://bugs.launchpad.net/bugs/1905493 Title: Services (apparmor, snapd.seeded, ...?) fail to start in nested lxd container Status in AppArmor: New Status in autopkgtest: New Status in cloud-init: Invalid Status in snapd: Confirmed Status in dbus package in Ubuntu: Confirmed Status in lxd package in Ubuntu: New Status in systemd package in Ubuntu: Invalid Bug description: When booting a nested lxd container inside another lxd container (just a normal container, not a VM) (i.e. just L2), using cloud-init -status --wait, the "." is just printed off infinitely and never returns. To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/1905493/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1968360] Re: jammy daily won't accept EC2 publickey (suspect cloud-init failure)
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3967 ** Bug watch added: github.com/canonical/cloud-init/issues #3967 https://github.com/canonical/cloud-init/issues/3967 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1968360 Title: jammy daily won't accept EC2 publickey (suspect cloud-init failure) Status in cloud-init: Invalid Status in openssh package in Ubuntu: Invalid Bug description: amazon-ebs: output will be in this color. ==> amazon-ebs: Prevalidating any provided VPC information ==> amazon-ebs: Prevalidating AMI Name: packer-honeycomb-arm-1649438444 amazon-ebs: Found Image ID: ami-03c980393156217bb ==> amazon-ebs: Creating temporary keypair: packer_62506eec-8c01-8c21-b199-32a96021bd7a ==> amazon-ebs: Creating temporary security group for this instance: packer_62506eee-c3da-1eb2-6e81-baa0c5ccfdfc ==> amazon-ebs: Authorizing access to port 22 from [0.0.0.0/0] in the temporary security groups... ==> amazon-ebs: Launching a source AWS instance... ==> amazon-ebs: Adding tags to source instance amazon-ebs: Adding tag: "Name": "Packer Builder" amazon-ebs: Instance ID: i-01158f222c8664f0c ==> amazon-ebs: Waiting for instance (i-01158f222c8664f0c) to become ready... ==> amazon-ebs: Using SSH communicator to connect: 54.173.181.221 ==> amazon-ebs: Waiting for SSH to become available... ==> amazon-ebs: Error waiting for SSH: Packer experienced an authentication error when trying to connect via SSH. This can happen if your username/password are wrong. You may want to double-check your credentials as part of your debugging process. original error: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain ==> amazon-ebs: Terminating the source AWS instance... ==> amazon-ebs: Cleaning up any extra volumes... ==> amazon-ebs: No volumes to clean up, skipping ==> amazon-ebs: Deleting temporary security group... ==> amazon-ebs: Deleting temporary keypair... Build 'amazon-ebs' errored after 2 minutes 42 seconds: Packer experienced an authentication error when trying to connect via SSH. This can happen if your username/password are wrong. You may want to double-check your credentials as part of your debugging process. original error: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain ==> Wait completed after 2 minutes 42 seconds ==> Some builds didn't complete successfully and had errors: --> amazon-ebs: Packer experienced an authentication error when trying to connect via SSH. This can happen if your username/password are wrong. You may want to double-check your credentials as part of your debugging process. original error: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain ==> Builds finished but no artifacts were created. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1968360/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1902960] Re: Upgrade from 245.4-4ubuntu3.3 to 245.4-4ubuntu3.2 appears to break DNS resolution in some cases
"It sounds to me like there's no cloud-init aspect here, so I'm going to move our tasks to Incomplete (so they'll expire out eventually). Please do set them back if I've missed something!" This expiration never happened, and no additional comments indicate that cloud-init has a problem, so I'm going to change cloud-init to Invalid. ** Changed in: cloud-init (Ubuntu) Status: Incomplete => Invalid ** Changed in: cloud-init (Ubuntu Focal) Status: Incomplete => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1902960 Title: Upgrade from 245.4-4ubuntu3.3 to 245.4-4ubuntu3.2 appears to break DNS resolution in some cases Status in cloud-images: New Status in systemd: New Status in cloud-init package in Ubuntu: Invalid Status in systemd package in Ubuntu: Fix Released Status in cloud-init source package in Focal: Invalid Status in systemd source package in Focal: Fix Released Status in cloud-init source package in Groovy: Won't Fix Status in systemd source package in Groovy: Fix Released Bug description: [impact] on boot of a specific azure instance, the ID_NET_DRIVER parameter of the instance's eth0 interface is not set. That leads to a failure of systemd-networkd to take control of the interface after a restart of systemd-networkd, which results in DNS failures (at first) and eventually complete loss of networking (once the DHCP lease expires). [test case] this occurs on first boot of an instance using the specific image; it is not reproducable using the latest ubuntu image nor any reboot of the affected image, and it has not been reproducable (for me) when using debug-enabled images based on the affected image. So, while the problem is reproducable using the specific image in question, it's not possible to verify the fix since any change to the image removes reproducability. however, while the problem itself can't be reproduced and then verified, if the assumption is correct (that the 'add' uevent is being missed on boot), that is possible to test and verify: $ udevadm info /sys/class/net/eth0 | grep ID_NET_DRIVER E: ID_NET_DRIVER=hv_netvsc $ sudo rm /run/udev/data/n2 (note, change 'n2' to whichever network interface index is correct) $ udevadm info /sys/class/net/eth0 | grep ID_NET_DRIVER $ sudo udevadm trigger -c change /sys/class/net/eth0 $ udevadm info /sys/class/net/eth0 | grep ID_NET_DRIVER (note the 'change' uevent did not populate ID_NET_DRIVER property) $ sudo udevadm trigger -c add /sys/class/net/eth0 $ udevadm info /sys/class/net/eth0 | grep ID_NET_DRIVER E: ID_NET_DRIVER=hv_netvsc (note the 'add' uevent did populate ID_NET_DRIVER) the test verification should result in ID_NET_DRIVER being populated for a 'change' uevent. [regression potential] any regression would likely involve problems with systemd-udevd processing 'change' events from network devices, and/or incorrect udevd device properties. [scope] this is needed only for focal and groovy. this is fixed by upstream commit e0e789c1e97 which is first included in v247, so this is fixed already in hirsute. while this commit is not included in bionic, due to the difficult nature of reproducing (and verifying) this, and the fact it has only been seen once on a focal image, I don't think it's appropriate to SRU to bionic at this point; possibly it may be appropriate if this is ever reproduced with a bionic image. [other info] note that this bug's subject and description, as well as the upstream systemd bug subject and description, talk about the problem being DNS resolution. However that is strictly a side-effect of the real problem and is not the actual issue. [original description] The systemd upgrade 245.4-4ubuntu3.3 to 245.4-4ubuntu3.2 appears to have broken DNS resolution across much of our Azure fleet earlier today. We ended up mitigating this by forcing reboots on the associated instances, no combination of networkctl reload, reconfigure, systemctl daemon-reexec, systemctl daemon-reload, netplan generate, netplan apply would get resolvectl to have a DNS server again. The main symptom appears to have been systemd-networkd believing it wasn't managing the eth0 interfaces: ubuntu@machine-1:~$ sudo networkctl IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 eth0 etherroutableunmanaged 2 links listed. Which eventually made them lose their DNS resolvers: ubuntu@machine-1:~$ sudo resolvectl dns Global: Link 2 (eth0): After rebooting, we see this behaving properly: ubuntu@machine-1:~$ sudo networkctl list IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 eth0 ether
[Touch-packages] [Bug 2019940] Re: Directly manipulating NetworkManager keyfiles
Invalid for cloud-init because the affected code is for rendering NetworkManager config on (non-Ubuntu) systems that are not using netplan. ** Changed in: cloud-init (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/2019940 Title: Directly manipulating NetworkManager keyfiles Status in augeas package in Ubuntu: New Status in calamares package in Ubuntu: New Status in cloud-init package in Ubuntu: Invalid Status in cruft-ng package in Ubuntu: New Status in dracut package in Ubuntu: New Status in forensic-artifacts package in Ubuntu: New Status in guestfs-tools package in Ubuntu: New Status in guix package in Ubuntu: New Status in ltsp package in Ubuntu: Invalid Status in netcfg package in Ubuntu: Won't Fix Status in netplan.io package in Ubuntu: Won't Fix Status in network-manager package in Ubuntu: New Status in refpolicy package in Ubuntu: New Status in sosreport package in Ubuntu: New Status in uhd package in Ubuntu: New Status in vagrant package in Ubuntu: New Bug description: The affected packages can manipulate NetworkManager keyfiles directly on disk, which might not be appropriate anymore on Ubuntu, since the Netplan integration was enabled in NetworkManager (starting with Mantic), migrating any keyfile configuration from /etc/NetworkManager/system-connections/*[.nmconnection] to /etc/netplan/90-NM-*.yaml See Netplan's documentation for how connections are handled: https://netplan.readthedocs.io/en/latest/netplan-everywhere/ PS: Packages were queried using: https://codesearch.debian.net/search?q=%2Fsystem-connections=1=1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/augeas/+bug/2019940/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
