This bug was fixed in the package cloud-init - 20.4-0ubuntu1
---
cloud-init (20.4-0ubuntu1) hirsute; urgency=medium
* d/control: add gnupg to Recommends as cc_apt_configure requires it to be
installed for some operations.
* New upstream release.
- Release 20.4 (#686)
This bug is believed to be fixed in cloud-init in version 20.4. If this
is still a problem for you, please make a comment and set the state back
to New
Thank you.
** Changed in: cloud-init
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a
New images with the patched datasource have been rolled out on the
platform.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1885527
Title:
cloud-init regenerating ssh-keys
To manage notifications
** Also affects: cloud-init
Importance: Undecided
Status: New
** Changed in: cloud-init
Status: New => Fix Committed
** Changed in: cloud-init
Importance: Undecided => Medium
** Changed in: cloud-init
Assignee: (unassigned) => Markus Schade (lp-markusschade)
--
You
** Changed in: cloud-init (Ubuntu)
Status: Confirmed => In Progress
** Changed in: cloud-init (Ubuntu)
Assignee: (unassigned) => Markus Schade (lp-markusschade)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://github.com/canonical/cloud-init/pull/630
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1885527
Title:
cloud-init regenerating ssh-keys
To manage notifications about this bug go to:
I co-wrote the datasource. ;-)
I will prepare a MR to add the following to our DS:
def check_instance_id(self, sys_cfg):
return sources.instance_id_matches_system_uuid(
self.get_instance_id(), 'system-serial-number')
That should take care of those cases and prevent an
@Markus,
Can you please provide a link to documentation showing that?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1885527
Title:
cloud-init regenerating ssh-keys
To manage notifications about
Hetzner also provides instance ID via DMI information (system-serial-
number). So this could be used as a fallback should the metadata service
not respond
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: cloud-init (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1885527
Title:
I've found the problem.
The cloud provider (in this case german Hetzner) provides a machine with a
virtual ethernet interface
# lspci | fgrep Ethernet
00:03.0 Ethernet controller: Red Hat, Inc. Virtio network device
which is, following the naming standards, named ens3
But then, the provider
** Changed in: cloud-init (Ubuntu)
Status: Expired => New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1885527
Title:
cloud-init regenerating ssh-keys
To manage notifications about this
[Expired for cloud-init (Ubuntu) because there has been no activity for
60 days.]
** Changed in: cloud-init (Ubuntu)
Status: Incomplete => Expired
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I opened bug 158 to request better documentation on this feature.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1885527
Title:
cloud-init regenerating ssh-keys
To manage notifications about
@Daniel,
> One convenience we could potentially provide: if cloud-init had a way
> for image creators to express "when next launched, cloud-init should
> treat that instance ID as immutable and permanent" (in a way that could
> be undone on subsequent boots, if a user wants to "unfreeze" an
** Changed in: cloud-init (Ubuntu)
Status: New => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1885527
Title:
cloud-init regenerating ssh-keys
To manage notifications about this
> It is definitely not Hetzner's task to fix Ubuntu.
To be clear, cloud-init is not used only on Ubuntu; I believe that
Hetzner's outage would have this effect across the majority of Linux
distributions.
And, that aside, I don't think this characterisation is fair: we're
suggesting that if
Yes, I do think this is unreasonable.
It is definitely not Hetzner's task to fix Ubuntu.
Especially since that process of re-initiialization of that instance ID
is neither obvious nor documented.
Looking at
https://cloudinit.readthedocs.io/
I did not yet find an explanation of what is going
** Changed in: cloud-init (Ubuntu)
Status: Incomplete => New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1885527
Title:
cloud-init regenerating ssh-keys
To manage notifications about this
If Hetzner has (or starts to provide) a way of determining instance ID
without using the network, we'd be more than happy to accept patches to
use that in cloud-init. However, as it sounds like the issue here is
Hetzner's internal services being unreliable, rather than a cloud-init
issue, I'm
@Valery,
Some cloud platforms provide the instance id via some non-network
channel (dmi data is common). In those cases, cloud-init will check
cached value versus the locally-available instance-id before looking for
a network available datasource.
So, if Hetzner provides that information in
We have no problem about cloud-init still being active on the machine
after the first boot init.
My issue is:
On first instance boot, the metadata service is successfully contacted,
and the initialisation succeed (host ssh key generated, hostname set,
...)
But on any reboot, if the metadata
"AGAIN: Why is cloud-init still manipulating the machine *after*
initialization and first boot?"
Because cloud-init thinks it is a "first boot". A supported use case for
cloud-init is:
* boot instance on cloud
* ssh in
* install some packages, prep this instance
* stop instance
* snapshot
** Changed in: cloud-init (Ubuntu)
Status: Incomplete => New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1885527
Title:
cloud-init regenerating ssh-keys
To manage notifications about this
I currently cannot give logs, since these were only temporary testing
machines in a cloud, that existed only for tens of minutes to test
installation procedures. I will supply logs as soon as a proceed with
testing and the problem occurs again.
However, I do not understand and did not find any
We have a similar issue:
1. At first boot cloud-init generated the host ssh keys
2. The metadata service crashed and went down :(
3. At reboot, cloud-init can NOT reach the metadata service and regenerates the
host ssh keys
--
You received this bug notification because you are a member of
after replying with collected logs, please set the status back to 'new'.
thanks for taking the time to file a bug.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1885527
Title:
cloud-init
Hi, please attach the output of 'cloud-init collect-logs' when run on a
system that demonstrates the problem.
cloud-init uses the "instance-id" from the metadata service to indicate
a new instance. Some things run once per instance, some things run once
per boot.
** Changed in: cloud-init
BTW,
docs at https://cloudinit.readthedocs.io completely fail to tell what
cloud-init actually is or is supposed to do.
It is not explaining that or why cloud-init survives the first boot and
remains active for future boots, and what this is good for.
There is no warning, no hint, no
29 matches
Mail list logo
