Unfortunately, no, I have no ETA.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2100963
Title:
cloud-init fails with MAAS since Feb 4 update
To manage notifications about this bug go to:
https://bu
networkctl output:
root@ip-192-168-11-242:/home/ubuntu# networkctl status
● Interfaces: 1, 2, 3
State: routable
Online state: online
Address: 192.168.11.242 on ens5
192.168.12.6 on ens6
** Description changed:
This integration test is currently failing on plucky:
https://github.com/canonical/cloud-init/blob/a136a979dd5a5084f71f5def5abf6d80d7cc263a/tests/integration_tests/test_networking.py#L313
This test will launch an ec2 instance, attach a 2nd NIC, and then assign
t
networkd debug logs attached from after reboot on plucky
** Attachment added: "networkd_debug_plucky"
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/2101860/+attachment/5864048/+files/networkd_debug_plucky
--
You received this bug notification because you are a member of Ubuntu
Bu
Also adding netplan and systemd here as the rendered networkd config
doesn't change, and the netplan apply call is racy.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2101860
Title:
Different networ
networkd debug logs attached from after reboot on oracular
** Attachment added: "networkd_debug_oracular"
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/2101860/+attachment/5864049/+files/networkd_debug_oracular
** Also affects: systemd (Ubuntu)
Importance: Undecided
Stat
It appears Plucky is missing the proper rule:
root@ip-192-168-11-242:~# ip rule
0: from all lookup local
32765: from 192.168.15.230 lookup 101 proto static
32766: from all lookup main
32767: from all lookup default
Compared to Oracular:
root@ip-192-168-1-227:/usr/lib/systemd/network# ip ru
Public bug reported:
This integration test is currently failing on plucky:
https://github.com/canonical/cloud-init/blob/a136a979dd5a5084f71f5def5abf6d80d7cc263a/tests/integration_tests/test_networking.py#L313
This test will launch an ec2 instance, attach a 2nd NIC, and then assign
two (total) I
> When removing the "use-routes" dhcp-overrides for ens6 and running
"netplan apply" it seems to be working.
The default for this is true, so unless the documentation is wrong, I
don't think that changing this is actually doing anything.
There is certainly some racy behavior though. Using a scrip
Plucky routes:
ubuntu@ip-192-168-11-242:~$ ip route
default via 192.168.0.1 dev ens5 proto dhcp src 192.168.11.242 metric 100
default via 192.168.0.1 dev ens6 proto dhcp src 192.168.12.6 metric 1003 mtu
9001
192.168.0.0/20 dev ens5 proto kernel scope link src 192.168.11.242 metric 100
192.168.0
Yes, we'll get it backported ASAP.
** Changed in: cloud-init (Ubuntu)
Status: New => Triaged
** Changed in: cloud-init (Ubuntu)
Status: Triaged => Fix Committed
** Changed in: cloud-init (Ubuntu)
Importance: Undecided => Critical
--
You received this bug notification because y
Is it possible to get the resulting tarball from `cloud-init collect-
logs`?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2100620
Title:
cloud-init not importing ssh keys
To manage notifications a
In addition to the regression tests posted above, tests for this
particular feature were tested on package build against a fake IMDS.
** Tags removed: verification-needed verification-needed-focal
verification-needed-jammy verification-needed-noble verification-needed-oracular
** Tags added: veri
Regression test results on EC2. Jammy failures are due to test changes
for netplan that haven't yet been SRUed.
** Attachment added: "test_results_2094858.tar.gz"
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/2094858/+attachment/5860861/+files/test_results_2094858.tar.gz
--
You r
This should be fixed in cloud-init version 25.1-0ubuntu2 .
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2098988
Title:
cloud-init datasource failure on Azure
To manage notifications about this bug
** Changed in: cloud-init (Ubuntu)
Status: Triaged => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2098988
Title:
cloud-init datasource failure on Azure
To manage notifications
** Tags removed: verification-needed verification-needed-focal
verification-needed-jammy verification-needed-noble verification-needed-oracular
** Tags added: verification-done verification-done-focal
verification-done-jammy verification-done-noble verification-done-oracular
--
You received thi
Test results
** Attachment added: "test_results_2097319.tar.gz"
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/2097319/+attachment/5860234/+files/test_results_2097319.tar.gz
** Tags removed: verification-needed verification-needed-focal
verification-needed-jammy verification-neede
Test results
** Attachment added: "test_results_2094179.tar.gz"
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/2094179/+attachment/5860136/+files/test_results_2094179.tar.gz
** Tags removed: verification-needed verification-needed-focal
verification-needed-jammy verification-neede
Test results attached
** Attachment added: "test_results_2094208.tar.gz"
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/2094208/+attachment/5859269/+files/test_results_2094208.tar.gz
** Tags removed: verification-needed verification-needed-focal
verification-needed-jammy verificat
Thanks for the offer to cloud-init! We'll likely take you up on that
soon.
It looks like your bug was something introduced in the last release, but it was
a particularly instance of a more general change in cloud-init. Cloud-init will
exit 2 when it hits recoverable errors. This is new behavior
Test results ensure /var is mounted are attached for each series.
** Attachment added: "test_results_2097441.tar.gz"
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/2097441/+attachment/5859141/+files/test_results_2097441.tar.gz
** Tags removed: verification-needed verification-neede
Test results attached. Tested cases where bootcmd are included and not
included in user data representing the cases that previously resulting
in waiting vs not waiting.
** Attachment added: "test_results_2094149.tar.gz"
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/2094149/+attachm
** Description changed:
[ Impact ]
There was an upstream change that moved
`RequiresMountsFor=/var/lib/cloud` from cloud-init-local.service to
cloud-init-main.service. Since cloud-init-main.service was patched out
of stable downstreams, this `RequiresMountsFor` line was accidentally
Thanks Jarrett, we'll get this fixed soon.
** Changed in: cloud-init (Ubuntu)
Importance: Undecided => Critical
** Changed in: cloud-init (Ubuntu)
Status: New => Triaged
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https
** Description changed:
[ Impact ]
On Digital Ocean and some bare metal instances, changes introduced in
e30549e8 are causing older instances to fail to boot. While the cloud-
init team cannot reproduce the exact scenario, we have received enough
reports that we believe it prudent rev
** Description changed:
[ Impact ]
On Digital Ocean and some bare metal instances, changes introduced in
e30549e8 are causing older instances to fail to boot. While the cloud-
init team cannot reproduce the exact scenario, we have received enough
reports that we believe it prudent rev
** Description changed:
[ Impact ]
There was an upstream change that moved
`RequiresMountsFor=/var/lib/cloud` from cloud-init-local.service to
cloud-init-main.service. Since cloud-init-main.service was patched out
of stable downstreams, this `RequiresMountsFor` line was accidentally
** Description changed:
[ Impact ]
There was an upstream change that moved
`RequiresMountsFor=/var/lib/cloud` from cloud-init-local.service to
cloud-init-main.service. Since cloud-init-main.service was patched out
of stable downstreams, this `RequiresMountsFor` line was accidentally
** Description changed:
[ Impact ]
- Originally reported upstream[1], an issue with systemd ordering caused by a
previous patch affects focal, jammy, and noble and causes NoCloud to be
undetected in some cases (identified when using LVM).
-
+ There was an upstream change that moved
+ `R
** Also affects: cloud-init (Ubuntu Focal)
Importance: Undecided
Status: New
** Also affects: cloud-init (Ubuntu Noble)
Importance: Undecided
Status: New
** Also affects: cloud-init (Ubuntu Jammy)
Importance: Undecided
Status: New
--
You received this bug notificat
For your other questions:
> Did you have any specific reasoning to not implement an escape hatch
to this infinite loop? Is it extra risk? Was it deemed unlikely, as
clouds would "never" have the metadata service return 503 for too long?
Or did you consider a stuck instance in a retry loop better t
That PR is not specific to EC2. If affects all datasources in that it
affects the response handling of every HTTP response that doesn't have
special error handling defined for it.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https:/
> Even so, if there is a script collecting this metric out there
somewhere, and just checking if port 22 is reachable, it will just see
this potential extra delay.
If we were to get a bug along these lines, I would close it as invalid
because the alternative is for the instance to not boot at all.
Our old documentation had this:
https://docs.cloud-init.io/en/24.1/development/module_creation.html
including the line "__doc__ = get_meta_doc(meta)".
That line was included in every single module for generating our
upstream documentation. This ceased in 24.2. In 24.2, this function had
no more m
> Where in this diff[1] is the change only impacting "Hetzner"?
Strictly, it's not, but that's the only datasource we know of that is
affected.
In early boot, before networking has started, cloud-init usually sets up
an Ephemeral DHCP connection so that it connect to the IMDS and then
tears that
Yes to your summary.
2094857 is unrelated. A 503 should not be ignored anywhere after this
change.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2094858
Title:
Cloud-init fails on AWS if IMDSv2 ret
No, documentation will not be produced the same, but that has been true
since 24.2
The documentation generation is for generating upstream docs at
https://docs.cloud-init.io/en/latest/ . I wouldn't really expect a user
with custom modules to be doing this. That would mean hosting an
entirely separ
> and still not fixed in 24.4.1
The function was only used in generating public documentation. It is no
longer used for that purpose, hence why we replaced it with a stub in
24.4.1. Why do you say still not fixed?
> Why was that method removed, and why isn't there a phasing out for it,
instead of
DataSourceExoscale.py was changed to log an error because that was one
of the few datasources that previously didn't log an error if the
process described in this Impact failed. Essentially this moved an error
log out from a section of code that we're ok with failing to a later
stage where we care
Andreas, I have updated the Impact and Test Plan accordingly. Please let
me know if you still have additional questions.
** Description changed:
[ Impact ]
- Cloud-init handles 503's generically as any other errors even though it
- is a message from the server of when and how to retry later.
Public bug reported:
[ Impact ]
Cloud-init handles 503's generically as any other errors even though it
is a message from the server of when and how to retry later. This is
issues within AWS.
[ Test Plan ]
Boot an instance. Observe a 503 from the IMDS when contacting the
metadata service. Ensur
Public bug reported:
[ Impact ]
Cloud-init checks for IMDS connectivity before setting up an ephemeral
network. In 24.4, this code was refactored to use a function that
supported multiple URLs rather than just one. If this function fails, it
logs an error, causing cloud-init to exit 2. On Hetzner
** Also affects: cloud-init (Ubuntu Noble)
Importance: Undecided
Status: New
** Also affects: cloud-init (Ubuntu Jammy)
Importance: Undecided
Status: New
** Also affects: cloud-init (Ubuntu Oracular)
Importance: Undecided
Status: New
** Also affects: cloud-init (Ubu
** Summary changed:
- cloud-init 24.4 prevents Ubuntu 20.04 Digital Ocean droplet from booting
+ Changes to cloud-init's systemd-networkd-wait-online interactions causing
boot failure
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
h
Public bug reported:
[ Impact ]
In cloud-init 24.4, custom signal handling code was added to log errors
when cloud-init received signals that resulted in cloud-init's death.
However, cloud-init legitimately needs to die when cloud-init triggers a
reboot, so these handlers caused unexpected errors
Public bug reported:
[ Impact ]
In 24.4, cloud-init made changes to document generation that removed the
need for a function called 'get_meta_doc()' that was used in document
generation. This resulted in a breaking change for any custom drop-in
modules following older best practices (e.g., https:
** Changed in: cloud-init (Ubuntu)
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2094149
Title:
cloud-init 24.4 prevents Ubuntu 20.04 Digital Ocean droplet from
booti
Public bug reported:
[ Impact ]
On Digital Ocean and some bare metal instances, changes introduced in
e30549e8 are causing older instances to fail to boot. While the cloud-
init team cannot reproduce the exact scenario, we have received enough
reports that we believe it prudent revert this change
Can I get some input from a subiquity dev on this? Cloud-init has both
this and https://bugs.launchpad.net/ubuntu/+source/cloud-
init/+bug/2092713 which is essentially the same bug but upgrading to a
different version of cloud-init.
Both are happening on a noble desktop install when upgrading from
** Changed in: cloud-init (Ubuntu)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2080150
Title:
Password Reset broken with CloudstackDatasource
To manag
** Tags removed: verification-needed verification-needed-focal
verification-needed-jammy verification-needed-noble verification-needed-oracular
** Tags added: verification-done verification-done-focal
verification-done-jammy verification-done-noble verification-done-oracular
--
You received thi
Chris Patterson from Microsoft confirmed via email that SRU testing
looks good on their end.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2089577
Title:
sru cloud-init (24.4 update) focal, jammy,
Cloud-init integration test result are attached. This includes Jenkins
runs for tests on focal, jammy, noble, and oracular on Azure, Ec2, Gce,
Lxd container, and Lxd VMs using generic and minimal images (where
applicable). Known failures are explained in `failures.txt` and
transient failures have b
While GH-5849 could have the same root cause, at first glance, the code
paths appear to be different. I think the cloud-init part of this issue
was closed prematurely. I'm setting this to incomplete until we can get
the full logs.
** Changed in: cloud-init (Ubuntu)
Status: Invalid => Incomp
Is it possible to get the full cloud-init logs as specified in
https://docs.cloud-init.io/en/latest/howto/bugs.html#collect-logs ? The
result is a tarball that also includes the cloud-init logs. The posted
'Full logs' link does not link to the full logs.
--
You received this bug notification beca
** Also affects: cloud-init (Ubuntu Jammy)
Importance: Undecided
Status: New
** Also affects: cloud-init (Ubuntu Focal)
Importance: Undecided
Status: New
** Also affects: cloud-init (Ubuntu Noble)
Importance: Undecided
Status: New
** Also affects: cloud-init (Ubuntu
** Description changed:
== Begin SRU Template ==
[Impact]
This release sports both bug-fixes and new features and we would like to
make sure all of our supported customers have access to these
improvements. The notable ones are:
- TODO
+ - feat(oracle): add true single stack ipv6 supp
Public bug reported:
== Begin SRU Template ==
[Impact]
This release sports both bug-fixes and new features and we would like to
make sure all of our supported customers have access to these
improvements. The notable ones are:
TODO
[Test Case]
The following development and SRU process was followe
** Changed in: cloud-init (Ubuntu)
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2079224
Title:
sru cloud-init (24.3.1 update) focal, jammy and noble
To man
> avoiding sshd_config.d all together
Why? Isn't this the entire point of the .d directory? The package
provides a default configuration. If another package or service (like
cloud-init) wants to change it, they should be dropping in an override
file. If cloud-init changes the config file it's less
This is fixed in https://github.com/canonical/cloud-init/pull/5701 and
will be available in cloud-init version 24.4
** Also affects: cloud-init (Ubuntu Noble)
Importance: Undecided
Status: New
** Changed in: cloud-init (Ubuntu Noble)
Status: New => Fix Committed
** Changed in: c
** Description changed:
- I Oracular 24.10, cloud-init 24.3.1 renamed cloud-init.service to cloud-
- init-network.service as part of the single-process mode support. This
- is only introduced in Oracular and not applicable to any stable releases
- before Oracular.[1]
+ In Oracular 24.10, cloud-in
Hi Danilo. The PPA works for me and fixes the problem for me. Thanks!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2078009
Title:
"netplan apply" not applying after cloud-init hotplug
To manage no
This bug is fixed in cloud-init 24.3, which should be hitting the Ubuntu
-proposed pocket soon. After being verified in -proposed, it will be
released to -updates.
** Changed in: cloud-init (Ubuntu)
Status: New => Fix Committed
--
You received this bug notification because you are a membe
This should be fixed as of https://github.com/canonical/cloud-
init/pull/5619 and should be present in cloud-init version 24.3.
** Changed in: cloud-init (Ubuntu)
Status: New => Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribe
Eh sorry, I think I misspoke. On a new python version we clear the
object pickle, not the entire instance cache. Ignore my previous
comment.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2075968
Title
I see `"lock_passwd": true` (a cloud-init default) in the instance-data-
sensitive.json file. Was the account manually unlocked at some point?
If so, when doing a release upgrade, cloud-init will see a new python
version, clear it's cache, then run as if it was first boot again.
--
You received
Got email confirmation from Azure folks that what is in proposed passes
their testing.
** Tags removed: verification-needed verification-needed-focal
verification-needed-jammy verification-needed-noble
** Tags added: verification-done verification-done-focal
verification-done-jammy verification-
Attached are the results of cloud-init integration testing for 24.2.
Integration tests were run on Focal, Jammy, and Noble for clouds Azure,
EC2, GCE, LXD Container, and LXD VM along with any necessary reruns.
Additionally, the Curtin cloud-init SRU job was also run and attached.
Reasons for fai
** Summary changed:
- sru cloud-init (24.2 update) to focal, jammy, mantic and noble
+ sru cloud-init (24.2 update) to focal, jammy and noble
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2071762
Tit
Should status here be changed to fix released? This works for me again
in Noble.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1974061
Title:
Fails on python3.10 (fix linked)
To manage notification
See https://github.com/canonical/cloud-init/pull/5437 for the cloud-init
fix.
** Changed in: cloud-init (Ubuntu)
Status: New => Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/20657
** Also affects: subiquity (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2069391
Title:
debsums reports file changed /usr/lib/systemd/system/clou
Verification results attached.
`verify_2066979.txt` contains results of manual verification as laid out in the
bug description.
`multinic-2066979-template.json` contains one of the supporting files used in
those tests.
`_integration_tests.txt` contains the automated regression integration
test
** Tags removed: verification-needed verification-needed-focal
verification-needed-jammy verification-needed-mantic verification-needed-noble
** Tags added: verification-done verification-done-focal
verification-done-jammy verification-done-mantic verification-done-noble
--
You received this bu
Verification results attached.
`verify_2066985.txt` contains results of manual verification as laid out in the
bug description.
`multinic-2066985-template.json` contains one of the supporting files used in
those tests.
`_integration_tests.txt` contains the automated regression integration
test
Public bug reported:
When launching a Focal instance on an single-NIC IPv6 EC2 instance and a
subnet that only allows IPv6, the instance does not bring up networking.
When connecting via the serial console, I find that the interface has no
IP address.
I checked back to 23.4 and this problem is st
Public bug reported:
[ Impact ]
Cloud-init recently added policy-based routing for netplan-only systems
on EC2. In order to gate the netplan-specific code, it checked to see in
the netplan activator was being used. However, if the datasource is
fetched in init-local timeframe (such as on EC2), it
** Description changed:
[ Impact ]
Cloud-init recently added policy based routing for multi-nic setups in
EC2. The added code assumed that "subnet-ipv4-cidr-block" would be
present in the metadata obtained from EC2's IMDS. However, on ipv6-only
instances, this is not true. The assumpt
** Also affects: cloud-init (Ubuntu Jammy)
Importance: Undecided
Status: New
** Also affects: cloud-init (Ubuntu Mantic)
Importance: Undecided
Status: New
** Also affects: cloud-init (Ubuntu Focal)
Importance: Undecided
Status: New
--
You received this bug notifica
Public bug reported:
[ Impact ]
Cloud-init recently added policy based routing for multi-nic setups in
EC2. The added code assumed that "subnet-ipv4-cidr-block" would be
present in the metadata obtained from EC2's IMDS. However, on ipv6-only
instances, this is not true. The assumption leads to a
The version of Python that is shipped with Ubuntu is what is supported
for the system. In the case of Focal, that is 3.8. It is fine to install
and use Python 3.9 for user applications, but when you run `update-
alternatives` to replace the default version of Python, you are now
forcing packages th
"when we install python3.9, we point /usr/bin/python to 3.9, but not
/usr/bin/python3"
cloud-init does use `python3` and not `python`, though I'm not sure that
would change anything.
$ head -1 /usr/bin/cloud-init
#!/usr/bin/python3
Since we can launch the AMI and cloud-init works ok out of the b
"We can test to see if installing python3-jinja2 moved us forward.
Standby."
That's good if that works, but I'm still not sure how this situation
happened. If I run `apt depends cloud-init`, I see `Depends:
python3-jinja2` as one of the dependencies. That means that even if
python3-jinja2 wasn't p
How are you running Python 3.9 in Focal? Are you using the cloud-init
package provided by Apt? Your error shows a crash due to the jinja2
library not existing, but jinja2 is a dependency of cloud-init. The
python3-jinja2 package should have been installed when you installed
cloud-init. Up until now
** Changed in: cloud-init (Ubuntu)
Importance: Critical => Undecided
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2066066
Title:
cloud-init startup failure with Python 3.9.5, Ubuntu Focal
To ma
** Changed in: cloud-init (Ubuntu)
Status: New => Triaged
** Changed in: cloud-init (Ubuntu)
Importance: Undecided => Critical
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2066066
Title:
** Description changed:
[ Impact ]
- * Environments or scripts which directly call cloud-init subcommands and
-provide an optional -f or --file argument to inject supplemental
-configuration after first boot will receive usage errors on the command
-line which will break any supp
** Also affects: subiquity (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2063813
Title:
cloud-init schema validation failure for: 'broadcast' (24
** Tags removed: verification-needed verification-needed-focal
verification-needed-jammy verification-needed-mantic
** Tags added: verification-done verification-done-focal
verification-done-jammy verification-done-mantic
--
You received this bug notification because you are a member of Ubuntu
Attached are the integration test runs for Focal, Jammy, and Mantic on
EC2, GCE, Azure, LXD containers, and LXD VMs. Curtin-cloud-init-sru
results are also attached.
Any failures are described in failures.txt along with "-rerun.txt"
containing reruns due to transient failures.
** Summary changed:
We intend this bug to be included in the SRU covered by
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/2056100 . Any
testing related to this bug will be included there.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https:/
Timo,
"test results are missing"
We don't attach test results until after the package has landed in
proposed.
"Also, the .changes file has a ref to #1946003, which is probably not
intended.."
Fixed in the latest uploads.
** Changed in: cloud-init (Ubuntu Focal)
Status: Incomplete => New
Due to cache invalidation happening every boot
(https://github.com/canonical/cloud-
init/blob/main/cloudinit/sources/__init__.py#L925), we also wind up
fetching metadata every boot. That has some rough edges to be addressed
separately, but it is currently giving us the behavior we desire, so I'm
go
Public bug reported:
This FFe would cause EC2 instance to fetch networking information every
boot and is implemented in https://github.com/canonical/cloud-
init/pull/5110 . Currently, EC2 only fetches that information first boot
and uses that cached information on subsequent boots.
https://github
In cloud-init 23.4, we added network config schema checking[1] to ensure
that any network config provided adheres to network configuration v1
format[2]. The cloud-init code to translate Oracle's networking
information into network v1[3] incorrectly includes a broadcast address
in the rendered confi
** Changed in: cloud-init (Ubuntu)
Status: New => Triaged
** Changed in: cloud-init (Ubuntu)
Importance: Undecided => High
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2056460
Title:
clo
** Description changed:
BACKGROUND:
cloud-init-local.service runs before networking has started. On non-
Oracle platforms, before networking has come up, cloud-init will create
an ephemeral connection to the cloud's IMDS using DHCP to retrieve
instance metadata. On Oracle, this normal
@bdrung , I realize that initramfs-tools may not be the culprit, but
given how Oracle uses iSCSI along with the recent dhcpcd changes, I
added it here too.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs
1 - 100 of 272 matches
Mail list logo
