On Sun, May 04, 2025 at 08:05:00AM +0200, Bastian Blank wrote:
> On Sat, May 03, 2025 at 10:57:39PM -0400, Noah Meyerhans wrote:
> > There shouldn't be any name resolution involved here at all. My guess
> > is that something is not recognizing the scoped link-local address as an
> > IP address, an
On Sat, May 03, 2025 at 10:57:39PM -0400, Noah Meyerhans wrote:
> There shouldn't be any name resolution involved here at all. My guess
> is that something is not recognizing the scoped link-local address as an
> IP address, and is treating it as a hostname that needs to be resolved
> in DNS. Whi
Control: tags -1 + upstream
Control: forwarded -1 https://github.com/canonical/cloud-init/issues/6205
On Sat, May 03, 2025 at 12:25:01PM +0330, Zar VPN wrote:
>This is a critical issue, as it prevents users from booting and
>configuring instances in modern IPv6-only cloud environments usin
Processing control commands:
> tags -1 + upstream
Bug #1104426 [cloud-init] cloud-init fails to handle IPv6-only environments in
Debian 12 generic-cloud
Added tag(s) upstream.
> forwarded -1 https://github.com/canonical/cloud-init/issues/6205
Bug #1104426 [cloud-init] cloud-init fails to
Dear all,
Thank you to everyone contributing to this discussion.
I would like to gently emphasize that the core issue reported in this bug
is the failure of cloud-init to fetch metadata over an IPv6-only network,
specifically when using the debian-12-genericcloud-amd64 image. This
results in a co
On Thu, May 01, 2025 at 10:49:01AM +0200, Bastian Blank wrote:
> On Thu, May 01, 2025 at 09:36:29AM +0330, Zar VPN wrote:
> > Unfortunately, this approach is not applicable in our case. We are using
> > the official `debian-12-genericcloud-amd64` image, which is specifically
> > designed for cloud
On Thu, May 01, 2025 at 09:36:29AM +0330, Zar VPN wrote:
> Unfortunately, this approach is not applicable in our case. We are using
> the official `debian-12-genericcloud-amd64` image, which is specifically
> designed for cloud environments and intentionally excludes certain
> hardware-related driv
> Since it sounds like you're experiencing this in an OpenStack cloud,
> one workaround would be to boot your server instance with
> configdrive enabled; cloud-init knows how to get its metadata that
> way as well.
Dear Jeremy,
Thank you for your response and the suggestion to enable configdrive
On May 1, 2025 01:21, Jeremy Stanley wrote:
>
> Since it sounds like you're experiencing this in an OpenStack cloud,
> one workaround would be to boot your server instance with
> configdrive enabled; cloud-init knows how to get its metadata that
> way as well.
> --
> Jeremy Stanley
Since it sounds like you're experiencing this in an OpenStack cloud,
one workaround would be to boot your server instance with
configdrive enabled; cloud-init knows how to get its metadata that
way as well.
--
Jeremy Stanley
root@localhost:/home/debian# cat /etc/netplan/50-cloud-init.yaml
network:
version: 2
ethernets:
enp3s0:
match:
macaddress: "fa:16:3e:b3:91:7c"
dhcp4: true
dhcp6: true
set-name: "enp3s0"
root@localhost:/home/debian# ip a
1: lo: mtu 65536 qdisc noqueue state U
Thank you for your response.
As requested, I tested the latest daily Trixie (Debian 13) cloud image from
https://cloud.debian.org/images/cloud/trixie/daily/.
Unfortunately, the same issue persists — cloud-init still fails to properly
fetch metadata in an IPv6-only environment, even though the met
On Wed, Apr 30, 2025 at 12:32:02AM +0330, Zar VPN wrote:
>Upon investigation, it appears that updating the cloud-init package to the
>latest version would resolve this issue. The latest versions of cloud-init
>include improved support for IPv6-only environments and should handle the
>
Package: cloud-init
Subject: cloud-init fails to handle IPv6-only environments in Debian 12
generic-cloud
Dear Debian Development Team,
I am writing to report an issue with the cloud-init package in the current
version of Debian 12 (Bookworm). In an IPv6-only environment, cloud-init
fails to pro
14 matches
Mail list logo
