Oracle metadata fetch fails on IPv6-only Resolute instances

[Chandan-M-N]

Description

Opening this issue to track a discussion and debug session regarding IPv6-only Oracle minimal instances.

On Ubuntu 26.04 (Resolute), cloud-init fails to fetch IMDS metadata. When comparing the boot behavior against Ubuntu 24.04 (Noble), we observed several differences in networking bring-up, timeouts, and early boot configuration.

Environment

• Cloud Provider: Oracle Cloud Infrastructure (OCI)
• Instance Type: IPv6-only VM
• OS Image: Ubuntu 26.04 (Resolute) minimal image
• cloud-init: 26.1-0ubuntu2
• Comparison Image: Ubuntu 24.04 (Noble) minimal image

Steps to Reproduce

1. Launch an IPv6-only Oracle Cloud instance using the Ubuntu 26.04 (Resolute) minimal image.
2. Allow the instance to boot.
3. Review /var/log/cloud-init-output.log and /var/log/cloud-init.log.

Expected Behavior

cloud-init should successfully establish an ephemeral network connection (or use the early boot network configuration) to route to the IPv6 IMDS endpoint ([fd00:c1::a9fe:a9fe]) and successfully fetch instance metadata.

Actual Behavior

cloud-init fails to fetch IMDS metadata. While cloud-init logs that the enp0s5 interface was successfully brought up for IPv6 ephemeral networking, it remains unable to route to the IPv6 IMDS address. Additionally, the parallel IPv4 DHCP fallback throws an expected but noisy error, and the IPv6 IMDS retry loop crashes due to a bug setting the timeout to 0.0.

---

Observations & Logs

resolute-cloud-init.tar.gz

1. Unroutable IMDS despite successful IPv6 bring-up (Resolute)
During ephemeral network setup, cloud-init attempts to bring up IPv4 and IPv6 in parallel.
For IPv4, dhcpcd uses --ipv4only and expectedly times out on the IPv6-only instance, logging an error:

2026-04-16 21:45:40,128 - dhcp.py[ERROR]: No valid DHCP lease configuration found in dhcpcd lease: ''

For IPv6, cloud-init logs that the ephemeral networking bring-up was actually successful:

ephemeral.py[DEBUG]: Successfully brought up enp0s5 for ephemeral ipv6 networking

Despite IPv6 networking being up, cloud-init is still unable to route to the IPv6 IMDS address at that point in time.

2. Timeout Bug in url_helper.py preventing retries
During the retries for the IPv6 IMDS, there is a separate bug where the timeout drops to 0.0.

url_helper.py[DEBUG]: Calling 'url' failed [29/30s]: unexpected error [Attempted to set connect timeout to 0.0, but the timeout cannot be set to a value less than or equal to 0.]

3. Noble vs. Resolute Network Bring-up Differences

noble-cloud-init.tar.gz

• Noble (Works): Initially shows no carrier on the primary NIC (Interface has no carrier: enp0s5), causing cloud-init to ignore it in the init-local timeframe. dhcpcd tries IPv4 and times out after sleep retry loops. After the IPv4 failure, IPv6 is successfully brought up, and it successfully fetches IMDS (DataSourceOracle.py[DEBUG]: Successfully fetched vnics metadata from IMDS at: http://[fd00:c1::a9fe:a9fe]/opc/v2/vnics/).
• Resolute (Fails): The carrier is present much earlier in systemd-networkd logs, even before cloud-init-main or cloud-init-local starts:

  Apr 16 21:45:06.476436 localhost systemd-networkd[383]: enp0s5: Configuring with /run/systemd/network/71-default.network.
  Apr 16 21:45:06.477202 localhost systemd-networkd[383]: enp0s5: Link UP
  Apr 16 21:45:06.477579 localhost systemd-networkd[383]: enp0s5: Gained carrier
  

---

Action Items & Suspected Root Causes (from @blackboxsw )

Based on the logs and conversation we had, Chad noted the following items that need to be addressed/investigated:

1. Reduce dhcp.py ERROR log level: It is okay for dhcpcd --ipv4only to fail because IPv4 and IPv6 ephemeral network setups are attempted in parallel and IPv6 can be successful. The log level should be reduced from ERROR.
2. Fix url_helper.py timeout bug: Fix the logic to avoid setting the timeout to 0.0 instead of 5.0 seconds during retries of IPv6 IMDS.
3. Investigate dracut / iSCSI differences: Chad suspects the missing routable connection to IMDS might be related to dracut behavior differences in Resolute.
   • cloud-init early boot detection previously relied on the presence of initramfs files in /run/net-*.conf and /run/net6-*.conf.
   • Because Resolute is dracut-based, these files are presumed absent, meaning network config info from the initramfs setup is missing.
   • The kernel cmdline in the Resolute case points to all things dracut and ISCSI, which appears to be where the problem lies.

[blackboxsw]

Thanks for filing this bug @Chandan-M-N and making cloud-init better.

The main difference appears to be cloud-init failing to detect DataSourceOracle during init-local timeframe and costing an extra 30 extra seconds due to failed retries against the IPv6 IMDS address.

I think more triage is necessary here related to dracut network setup in resolute and initial config which I don't have prioritized on my time at the moment.

What I think cloud-init can look toward resolving related to this issue are the items 1 & 2 that are raised above:

1. avoiding incorrect ERROR level log on dhcpcd ipv4 failure due to being on an IPv6-only system.
2. avoid truncating timeout during IMDS retries resulting in unexpected error [Attempted to set connect timeout to 0.0...

One thing I'm seeing in the resolute logs versus noble logs is that resolute kernel command-line is providing the many potentially conflicting initramfs and dracut-related params:

libiscsi.debug_libiscsi_eh=1 iscsi_auto_skip_initramfs_networking rd.net.timeout.carrier=5 rd.iscsi.param=node.session.timeo.replacement_timeout=6000 net.ifnames=1 libiscsi.debug_libiscsi_eh=1 rd.net.timeout.dhcp=10 ip=dhcp netroot=iscsi rd.iscsi.firmware=1

1. note presence of innocuous duplicated libiscsi.debug_libiscsi_eh=1

2. I believe providing these iscsi_auto_skip_initramfs_networking , ip=dhcp and rs.iscsi.firmare=1 may cause some potential conflicts in system setup where dracut might only fallback to dhcp-ipv4 if iscsi.firmware doesn't contain config.

3. On a booted system with ipv6-only, we don't see dracut-specific network configuration files in /run/initramfs, just a bunch of empty directories which tells me dracut is not setting up configuring network on this system:

 /run/initramfs/
/run/initramfs/systemd
/run/initramfs/systemd/ephemeral-trees
/run/initramfs/systemd/coredump
/run/initramfs/systemd/network
/run/initramfs/log
/run/initramfs/log/private
/run/initramfs/cmdline.d

4. Additionally, systemd-networkd is dumping a network config that will be inapplicable on an ipv6-only environment into /run/systemd/network/71-default.network as this file only has IPV4-based DHCP config:

# Automatically generated by systemd-network-generator

[Match]
Kind=!*
Type=!loopback

[Link]

[Network]
DHCP=ipv4

[DHCP]

I'm uncertain whether this is expected behavior or not from resolute's systemd-networkd (no dhcpv6 config) and dracut-based initramfs on iSCSI systems in Oracle. This will need some other eyes to look it over to understand those expectations.

[blackboxsw]

@Chandan-M-N a second major difference is that the noble image launched contains cloud-init 25.3. Just to be sure we are comparing apples to apples, can we launch an image on Noble with cloud-init installed from cloud-init's proposed release PPA which also has cloud-init version 26.1 after a sudo cloud-init clean --logs -c all --reboot? This will at least also confirm that we are comparing similar cloud-init versions to rule out any cloud-init differences between versions. Can we please attach logs from a noble run with cloud-init version 26.1?

[Chandan-M-N]

Logs for noble using cloud-init 26.1-0ubuntu1~24.04.1

noble-cloud-init-26.1.tar.gz