** Also affects: cloud-init
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1987393
Title:
autopkgtest-buildvm-ubuntu-cloud hangs on
** Changed in: cloud-images
Status: Expired => Incomplete
** Changed in: cloud-init
Status: Expired => Incomplete
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1940791
Thanks for looking into this. I thought about pivoting into /target too,
that should save us from worrying about mounts at all, but requires
changes in how subiquity operates, and in general moves a bit away from
the idea that installs done from ISO should be treatable like cloud
instances, which
Public bug reported:
When cloud-init is used to configure a new Ubuntu Server system
installed from the ISO images, and /home is configured as a separate
partition, there is a (slow) race between the user creation and /home
being mounted. This can lead to the user $HOME being created in the
wrong
Public bug reported:
As usual we periodically need to:
- Fix the issue with the newer linters
- Update the pinned deps in tox.ini
Reproducer:
- tox -e tip-pylint
Log excerpt:
* Module cloudinit.subp
cloudinit/subp.py:238: [W1514(unspecified-encoding), subp] Using open without
Lintian is now rather happy with the package (both source and binary),
with just one warning remaining:
W: cloud-init: command-with-path-in-maintainer-script postinst:296
/usr/sbin/grub-install
Explanation: https://lintian.debian.org/tags/command-with-path-in-
maintainer-script
I'll submit a PR
This was merged long ago.
** Changed in: cloud-init
Assignee: Paride Legovini (paride) => (unassigned)
** Changed in: cloud-init
Status: Triaged => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to
Public bug reported:
Sample error:
def test_keyserver(self, class_client: IntegrationInstance):
"""Test the apt keyserver functionality.
Ported from
** Changed in: cloud-init
Status: Triaged => Fix Released
** Changed in: cloud-images
Status: New => Fix Committed
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1896604
-init
Status: New => Triaged
** Changed in: cloud-init
Assignee: (unassigned) => Paride Legovini (paride)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1896604
Title:
** Changed in: cloud-init (Ubuntu)
Status: Fix Released => New
** Changed in: cloud-init
Assignee: (unassigned) => Paride Legovini (paride)
** Changed in: cloud-init
Status: New => Triaged
--
You received this bug notification because you are a member of Yahoo!
En
This is happening again with Focal and Groovy:
tox -e citest -- run --os-name=focal --platform=lxd --preserve-data
--data-dir=results --verbose --deb=cloud-
init_20.2-134-g747723a4-1\~bddeb_all.deb --test-
config=tests/cloud_tests/testcases/modules/lxd_bridge.yaml
Public bug reported:
Use of apt-key is deprecated and it will last be available in Debian 11
and Ubuntu 22.04, see apt-key(8).
Cloud-init uses `apt-key add`, which can be replaced by dropping the
pubkeys to be trusted in the /etc/apt/trusted.gpg.d/ directory. The
`apt-key list` and `apt-key
** Changed in: cloud-utils
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1876139
Title:
Groovy cloud-images failing during growpart
Hi Jason,
Thanks for taking the time to report this issue and to follow-up with
your findings.
As apparently this isn't a bug in cloud-init I'm setting the status of
this report to Invalid. Should you not agree please don't hesitate to
change its status back to New, explain why you still believe
I updated some tasks:
- identicurse: removed from Groovy => Fix Released
- jsonbot: removed from Bionic => Fix Released
- python-django-piston: removed from Eoan => Fix Released
- turpial: removed from Xenial => Fix Releaed
- tweepy: dependency dropped in Xenial => Fix Released
- u1db: pkg
Hi and thanks for filing this bug report.
I believe this is a bug in subiquity (the Ubuntu Server installer)
rather than a bug in cloud-init. I am reassigning it.
** Also affects: subiquity
Importance: Undecided
Status: New
** Changed in: cloud-init
Status: New => Incomplete
As per IRC discussion with @OddBloke, this whole problem will go away
with the next Focal SRU. We'll stand the bddeb failures up to that
point, they're not worth a non-trivial fix.
** Changed in: cloud-init
Status: New => Won't Fix
--
You received this bug notification because you are a
Public bug reported:
When the packages/bddeb script is called from the ubuntu/focal branch it
constructs a source package with missing build dependencies (pytest and
pytest-cov). The package is therefore unsuitable for testing.
The problem is due to the fact that the missing dependencies are
Reported as working on askubuntu by the person who originally posted the
question; I think everything is working as intended. I'm setting this to
Invalid, no need to tell you to swiftly set it back to New if anything
remains unclear.
** Changed in: cloud-init
Status: New => Invalid
--
I'm not marking this Fix Released for subiquity as the change has not
been released in all the subiquity channels yet.
** Changed in: cloud-init
Status: New => Invalid
** Changed in: subiquity
Status: New => Fix Committed
--
You received this bug notification because you are a
Public bug reported:
The cloud-init test environment can't be set up on CentOS 8 due to
missing Python 3 dependencies. The missing libraries are at least the
following:
- contextlib2
- httpretty
- unittest2
Of these unittest2 is available in the PowerTools repository as
python3-unittest2,
Hello magnate, thanks for your report.
This looks like a local configuration problem, rather than a bug in
cloud-init. The cloud-init package (like all the packages in Ubuntu) do
not install things in /usr/local/, so the cloud-init file you are trying
to run does not come from the Ubuntu package.
** Changed in: cloud-init
Status: Expired => Incomplete
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1841182
Title:
cloud-init fails when rebooting EC2 i3.metal instances
Public bug reported:
Integration tests on Eoan are failing on the lxd and nocloud kvm
platforms. In both cases the test system is not reachable via SSH.
LXD log: https://paste.ubuntu.com/p/r2hwqZQfm2/
KVM log: https://paste.ubuntu.com/p/W3N22yBxKN/
This failure mode began with the test run of
Public bug reported:
The newly released pylint 2.4.0 detects variable self-assignments and
throws a W0127 when one is found. There are four of these self-
assignments in cloud-init, all in this form:
@skipUnlessJsonSchema()
class TestSchema(CiTestCase, SchemaTestCaseMixin):
with_logs = True
Thanks for reaching back. Bugs are closed by setting them to a
"terminal" state, in this case "Invalid" is the most appropriate one.
** Changed in: cloud-init
Status: Incomplete => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is
Public bug reported:
cloud-init's systemd service file (cloud-init.service) currently has not
timeout; it explicitly sets:
TimeoutSec=0
which, while not explicitly documented in systemd-service(5), appears to
disable the timeout logic. This may cause the boot process to get stuck,
while the
Public bug reported:
In order to collect boot-speed metrics I deploy/reboot/terminate several
EC2 instances per day. At a high level this is that the jobs do:
1. Deploy an instance and wait for cloud-init
to finish using `cloud-init status --wait`
2. Collect and retrieve some logs via
29 matches
Mail list logo
