[Touch-packages] [Bug 2056194] Re: Networking broken in early boot on Oracle Native instances due to MTU settings
This bug was fixed in the package initramfs-tools - 0.142ubuntu23 --- initramfs-tools (0.142ubuntu23) noble; urgency=medium [ Daniel van Vugt ] * hooks/framebuffer: Only add simple/tiny framebuffer drivers. This is to limit the size of initrd when FRAMEBUFFER=y is soon enabled for desktop installations (LP: #1970069, #1869655). [ Benjamin Drung ] * autopkgtest: Increase QEMU timeouts on arm64/armhf * hooks/framebuffer: - Move adding framebuffer drivers into auto_add_modules - Drop looking in $MODULESDIR/initrd/ for kernel modules - Support MODULES=dep in framebuffer hook initramfs-tools (0.142ubuntu22) noble; urgency=medium * autopkgtest: update systemd-udevd path from /lib to /usr/lib initramfs-tools (0.142ubuntu21) noble; urgency=medium [ Benjamin Drung ] * configure_networking: - Increase minimum timeout to 30 seconds - Fix configuring BOOTIF when using iSCSI (LP: #2056187) - Set interface MTU if provided by the DHCP server (LP: #2056194) - log sleep durations before retries * Copy /etc/passwd into the initramfs to allow dhcpcd running as dhcpcd user * Replace obsolete pkg-config build-dependency by pkgconf [ Dan Bungert ] * Restore nvdimm and dax pmem-related modules (LP: #1981385) -- Benjamin Drung Thu, 21 Mar 2024 10:57:54 +0100 ** Changed in: initramfs-tools (Ubuntu) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/2056194 Title: Networking broken in early boot on Oracle Native instances due to MTU settings Status in cloud-images: New Status in cloud-init package in Ubuntu: Fix Released Status in initramfs-tools package in Ubuntu: Fix Released Bug description: 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 normally isn't necessary as we boot with connectivity to the IMDS out of the box. This can be seen in the following Jammy instance using an SR-IOV NIC: 2024-03-05 14:09:05,351 - url_helper.py[DEBUG]: [0/1] open 'http://169.254.169.254/opc/v2/instance/' with {'url': 'http://169.254.169.254/opc/v2/instance/', 'stream': False, 'allow_redirects': True, 'method': 'GET', 'timeout': 5.0, 'headers': {'User-Agent' : 'Cloud-Init/23.3.3-0ubuntu0~22.04.1', 'Authorization': 'Bearer Oracle'}} configuration 2024-03-05 14:09:05,362 - url_helper.py[DEBUG]: Read from http://169.254.169.254/opc/v2/instance/ (200, 2663b) after 1 attempts 2024-03-05 14:09:05,362 - ephemeral.py[DEBUG]: Skip ephemeral DHCP setup, instance has connectivity to {'url': 'http://169.254.169.254/opc/v2/instance/', 'headers': {'Authorization': 'Bearer Oracle'}, 'timeout': 5} 2024-03-05 14:09:05,362 - url_helper.py[DEBUG]: [0/3] open 'http://169.254.169.254/opc/v2/instance/' with {'url': 'http://169.254.169.254/opc/v2/instance/', 'stream': False, 'allow_redirects': True, 'method': 'GET', 'headers': {'User-Agent': 'Cloud-Init/23 .3.3-0ubuntu0~22.04.1', 'Authorization': 'Bearer Oracle'}} configuration 2024-03-05 14:09:05,368 - url_helper.py[DEBUG]: Read from http://169.254.169.254/opc/v2/instance/ (200, 2663b) after 1 attempts Notice the "Skip ephemeral DHCP setup, instance has connectivity". This means that cloud-init has determined that it already has connectivity and doesn't need to do any additional setup to retrieve data from the IMDS. We can also see the same behavior on a Noble paravirtualized instance: 2024-03-01 20:51:33,482 - url_helper.py[DEBUG]: [0/1] open 'http://169.254.169.254/opc/v2/instance/' with {'url': 'http://169.254.169.254/opc/v2/instance/', 'stream': False, 'allow_redirects': True, 'method': 'GET', 'timeout': 5.0, 'headers': {'User-Agent': 'Cloud-Init/24.1~7g54599148-0ubuntu1', 'Authorization': 'Bearer Oracle'}} configuration 2024-03-01 20:51:33,488 - url_helper.py[DEBUG]: Read from http://169.254.169.254/opc/v2/instance/ (200, 3067b) after 1 attempts 2024-03-01 20:51:33,488 - ephemeral.py[DEBUG]: Skip ephemeral DHCP setup, instance has connectivity to {'url': 'http://169.254.169.254/opc/v2/instance/', 'headers': {'Authorization': 'Bearer Oracle'}, 'timeout': 5} 2024-03-01 20:51:33,489 - url_helper.py[DEBUG]: [0/3] open 'http://169.254.169.254/opc/v2/instance/' with {'url': 'http://169.254.169.254/opc/v2/instance/', 'stream': False, 'allow_redirects': True, 'method': 'GET', 'headers': {'User-Agent': 'Cloud-Init/24.1~7g54599148-0ubuntu1', 'Authorization': 'Bearer Oracle'}} configuration 2024-03-01 20:51:33,500 - url_helper.py[DEBUG]: Read from http://169.254.169.254/opc/v2/instance/ (200, 3067b) after 1 attempts 2024-03-01 20:51:33,501 - util.py[DEBUG]: Writing to
[Touch-packages] [Bug 2056194] Re: Networking broken in early boot on Oracle Native instances due to MTU settings
** Merge proposal unlinked: https://code.launchpad.net/~vanvugt/ubuntu/+source/initramfs-tools/+git/initramfs-tools/+merge/462481 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/2056194 Title: Networking broken in early boot on Oracle Native instances due to MTU settings Status in cloud-images: New Status in cloud-init package in Ubuntu: Fix Released Status in initramfs-tools package in Ubuntu: Fix Committed Bug description: 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 normally isn't necessary as we boot with connectivity to the IMDS out of the box. This can be seen in the following Jammy instance using an SR-IOV NIC: 2024-03-05 14:09:05,351 - url_helper.py[DEBUG]: [0/1] open 'http://169.254.169.254/opc/v2/instance/' with {'url': 'http://169.254.169.254/opc/v2/instance/', 'stream': False, 'allow_redirects': True, 'method': 'GET', 'timeout': 5.0, 'headers': {'User-Agent' : 'Cloud-Init/23.3.3-0ubuntu0~22.04.1', 'Authorization': 'Bearer Oracle'}} configuration 2024-03-05 14:09:05,362 - url_helper.py[DEBUG]: Read from http://169.254.169.254/opc/v2/instance/ (200, 2663b) after 1 attempts 2024-03-05 14:09:05,362 - ephemeral.py[DEBUG]: Skip ephemeral DHCP setup, instance has connectivity to {'url': 'http://169.254.169.254/opc/v2/instance/', 'headers': {'Authorization': 'Bearer Oracle'}, 'timeout': 5} 2024-03-05 14:09:05,362 - url_helper.py[DEBUG]: [0/3] open 'http://169.254.169.254/opc/v2/instance/' with {'url': 'http://169.254.169.254/opc/v2/instance/', 'stream': False, 'allow_redirects': True, 'method': 'GET', 'headers': {'User-Agent': 'Cloud-Init/23 .3.3-0ubuntu0~22.04.1', 'Authorization': 'Bearer Oracle'}} configuration 2024-03-05 14:09:05,368 - url_helper.py[DEBUG]: Read from http://169.254.169.254/opc/v2/instance/ (200, 2663b) after 1 attempts Notice the "Skip ephemeral DHCP setup, instance has connectivity". This means that cloud-init has determined that it already has connectivity and doesn't need to do any additional setup to retrieve data from the IMDS. We can also see the same behavior on a Noble paravirtualized instance: 2024-03-01 20:51:33,482 - url_helper.py[DEBUG]: [0/1] open 'http://169.254.169.254/opc/v2/instance/' with {'url': 'http://169.254.169.254/opc/v2/instance/', 'stream': False, 'allow_redirects': True, 'method': 'GET', 'timeout': 5.0, 'headers': {'User-Agent': 'Cloud-Init/24.1~7g54599148-0ubuntu1', 'Authorization': 'Bearer Oracle'}} configuration 2024-03-01 20:51:33,488 - url_helper.py[DEBUG]: Read from http://169.254.169.254/opc/v2/instance/ (200, 3067b) after 1 attempts 2024-03-01 20:51:33,488 - ephemeral.py[DEBUG]: Skip ephemeral DHCP setup, instance has connectivity to {'url': 'http://169.254.169.254/opc/v2/instance/', 'headers': {'Authorization': 'Bearer Oracle'}, 'timeout': 5} 2024-03-01 20:51:33,489 - url_helper.py[DEBUG]: [0/3] open 'http://169.254.169.254/opc/v2/instance/' with {'url': 'http://169.254.169.254/opc/v2/instance/', 'stream': False, 'allow_redirects': True, 'method': 'GET', 'headers': {'User-Agent': 'Cloud-Init/24.1~7g54599148-0ubuntu1', 'Authorization': 'Bearer Oracle'}} configuration 2024-03-01 20:51:33,500 - url_helper.py[DEBUG]: Read from http://169.254.169.254/opc/v2/instance/ (200, 3067b) after 1 attempts 2024-03-01 20:51:33,501 - util.py[DEBUG]: Writing to /run/cloud-init/cloud-id-oracle - wb: [644] 7 bytes PROBLEM: On a Noble instance using Hardware-assisted (SR-IOV) networking, this is not working. cloud-init-local.service no longer has immediate connectivity to the IMDS. Since it cannot connect, in then attempts to create an ephemeral connection to the IMDS using DHCP. It is able to obtain a DHCP lease, but then when it tries to connect to the IMDS, the call just hangs. The call has no timeout, so this results in an instance that cannot be logged into even via the serial console because cloud-init is blocking the rest of boot. A simple cloud-init workaround is to add something along the lines of `timeout=2` to https://github.com/canonical/cloud- init/blob/main/cloudinit/sources/DataSourceOracle.py#L349 . This allows cloud-init to boot. Looking at the logs, we can see that cloud- init is unable to connect to the IMDS: 2024-03-05 14:23:54,836 - ephemeral.py[DEBUG]: Received dhcp lease on ens3 for 10.0.0.133/255.255.255.0 2024-03-05 14:23:54,837 - url_helper.py[DEBUG]: [0/3] open 'http://169.254.169.254/opc/v2/instance/' with {'url': 'http://169.254.169.254/opc/v2/instance/', 'stream': False, 'allow_redirects': True, 'method': 'GET', 'timeout': 2.0, 'headers': {'User-Agent':
[Touch-packages] [Bug 2056194] Re: Networking broken in early boot on Oracle Native instances due to MTU settings
** Merge proposal linked: https://code.launchpad.net/~vanvugt/ubuntu/+source/initramfs-tools/+git/initramfs-tools/+merge/462481 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/2056194 Title: Networking broken in early boot on Oracle Native instances due to MTU settings Status in cloud-images: New Status in cloud-init package in Ubuntu: Fix Released Status in initramfs-tools package in Ubuntu: Fix Committed Bug description: 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 normally isn't necessary as we boot with connectivity to the IMDS out of the box. This can be seen in the following Jammy instance using an SR-IOV NIC: 2024-03-05 14:09:05,351 - url_helper.py[DEBUG]: [0/1] open 'http://169.254.169.254/opc/v2/instance/' with {'url': 'http://169.254.169.254/opc/v2/instance/', 'stream': False, 'allow_redirects': True, 'method': 'GET', 'timeout': 5.0, 'headers': {'User-Agent' : 'Cloud-Init/23.3.3-0ubuntu0~22.04.1', 'Authorization': 'Bearer Oracle'}} configuration 2024-03-05 14:09:05,362 - url_helper.py[DEBUG]: Read from http://169.254.169.254/opc/v2/instance/ (200, 2663b) after 1 attempts 2024-03-05 14:09:05,362 - ephemeral.py[DEBUG]: Skip ephemeral DHCP setup, instance has connectivity to {'url': 'http://169.254.169.254/opc/v2/instance/', 'headers': {'Authorization': 'Bearer Oracle'}, 'timeout': 5} 2024-03-05 14:09:05,362 - url_helper.py[DEBUG]: [0/3] open 'http://169.254.169.254/opc/v2/instance/' with {'url': 'http://169.254.169.254/opc/v2/instance/', 'stream': False, 'allow_redirects': True, 'method': 'GET', 'headers': {'User-Agent': 'Cloud-Init/23 .3.3-0ubuntu0~22.04.1', 'Authorization': 'Bearer Oracle'}} configuration 2024-03-05 14:09:05,368 - url_helper.py[DEBUG]: Read from http://169.254.169.254/opc/v2/instance/ (200, 2663b) after 1 attempts Notice the "Skip ephemeral DHCP setup, instance has connectivity". This means that cloud-init has determined that it already has connectivity and doesn't need to do any additional setup to retrieve data from the IMDS. We can also see the same behavior on a Noble paravirtualized instance: 2024-03-01 20:51:33,482 - url_helper.py[DEBUG]: [0/1] open 'http://169.254.169.254/opc/v2/instance/' with {'url': 'http://169.254.169.254/opc/v2/instance/', 'stream': False, 'allow_redirects': True, 'method': 'GET', 'timeout': 5.0, 'headers': {'User-Agent': 'Cloud-Init/24.1~7g54599148-0ubuntu1', 'Authorization': 'Bearer Oracle'}} configuration 2024-03-01 20:51:33,488 - url_helper.py[DEBUG]: Read from http://169.254.169.254/opc/v2/instance/ (200, 3067b) after 1 attempts 2024-03-01 20:51:33,488 - ephemeral.py[DEBUG]: Skip ephemeral DHCP setup, instance has connectivity to {'url': 'http://169.254.169.254/opc/v2/instance/', 'headers': {'Authorization': 'Bearer Oracle'}, 'timeout': 5} 2024-03-01 20:51:33,489 - url_helper.py[DEBUG]: [0/3] open 'http://169.254.169.254/opc/v2/instance/' with {'url': 'http://169.254.169.254/opc/v2/instance/', 'stream': False, 'allow_redirects': True, 'method': 'GET', 'headers': {'User-Agent': 'Cloud-Init/24.1~7g54599148-0ubuntu1', 'Authorization': 'Bearer Oracle'}} configuration 2024-03-01 20:51:33,500 - url_helper.py[DEBUG]: Read from http://169.254.169.254/opc/v2/instance/ (200, 3067b) after 1 attempts 2024-03-01 20:51:33,501 - util.py[DEBUG]: Writing to /run/cloud-init/cloud-id-oracle - wb: [644] 7 bytes PROBLEM: On a Noble instance using Hardware-assisted (SR-IOV) networking, this is not working. cloud-init-local.service no longer has immediate connectivity to the IMDS. Since it cannot connect, in then attempts to create an ephemeral connection to the IMDS using DHCP. It is able to obtain a DHCP lease, but then when it tries to connect to the IMDS, the call just hangs. The call has no timeout, so this results in an instance that cannot be logged into even via the serial console because cloud-init is blocking the rest of boot. A simple cloud-init workaround is to add something along the lines of `timeout=2` to https://github.com/canonical/cloud- init/blob/main/cloudinit/sources/DataSourceOracle.py#L349 . This allows cloud-init to boot. Looking at the logs, we can see that cloud- init is unable to connect to the IMDS: 2024-03-05 14:23:54,836 - ephemeral.py[DEBUG]: Received dhcp lease on ens3 for 10.0.0.133/255.255.255.0 2024-03-05 14:23:54,837 - url_helper.py[DEBUG]: [0/3] open 'http://169.254.169.254/opc/v2/instance/' with {'url': 'http://169.254.169.254/opc/v2/instance/', 'stream': False, 'allow_redirects': True, 'method': 'GET', 'timeout': 2.0, 'headers': {'User-Agent':
[Touch-packages] [Bug 2056194] Re: Networking broken in early boot on Oracle Native instances due to MTU settings
This bug was fixed in the package cloud-init - 24.1.1-0ubuntu1 --- cloud-init (24.1.1-0ubuntu1) noble; urgency=medium * Upstream snapshot based on 24.1.1. List of changes from upstream can be found at https://raw.githubusercontent.com/canonical/cloud-init/24.1.1/ChangeLog - Bugs fixed in this snapshot: (LP: #2056439, #2056460, #2055077) (LP: #2056194) -- Brett Holman Mon, 11 Mar 2024 21:09:37 -0600 ** Changed in: cloud-init (Ubuntu) Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/2056194 Title: Networking broken in early boot on Oracle Native instances due to MTU settings Status in cloud-images: New Status in cloud-init package in Ubuntu: Fix Released Status in initramfs-tools package in Ubuntu: Fix Committed Bug description: 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 normally isn't necessary as we boot with connectivity to the IMDS out of the box. This can be seen in the following Jammy instance using an SR-IOV NIC: 2024-03-05 14:09:05,351 - url_helper.py[DEBUG]: [0/1] open 'http://169.254.169.254/opc/v2/instance/' with {'url': 'http://169.254.169.254/opc/v2/instance/', 'stream': False, 'allow_redirects': True, 'method': 'GET', 'timeout': 5.0, 'headers': {'User-Agent' : 'Cloud-Init/23.3.3-0ubuntu0~22.04.1', 'Authorization': 'Bearer Oracle'}} configuration 2024-03-05 14:09:05,362 - url_helper.py[DEBUG]: Read from http://169.254.169.254/opc/v2/instance/ (200, 2663b) after 1 attempts 2024-03-05 14:09:05,362 - ephemeral.py[DEBUG]: Skip ephemeral DHCP setup, instance has connectivity to {'url': 'http://169.254.169.254/opc/v2/instance/', 'headers': {'Authorization': 'Bearer Oracle'}, 'timeout': 5} 2024-03-05 14:09:05,362 - url_helper.py[DEBUG]: [0/3] open 'http://169.254.169.254/opc/v2/instance/' with {'url': 'http://169.254.169.254/opc/v2/instance/', 'stream': False, 'allow_redirects': True, 'method': 'GET', 'headers': {'User-Agent': 'Cloud-Init/23 .3.3-0ubuntu0~22.04.1', 'Authorization': 'Bearer Oracle'}} configuration 2024-03-05 14:09:05,368 - url_helper.py[DEBUG]: Read from http://169.254.169.254/opc/v2/instance/ (200, 2663b) after 1 attempts Notice the "Skip ephemeral DHCP setup, instance has connectivity". This means that cloud-init has determined that it already has connectivity and doesn't need to do any additional setup to retrieve data from the IMDS. We can also see the same behavior on a Noble paravirtualized instance: 2024-03-01 20:51:33,482 - url_helper.py[DEBUG]: [0/1] open 'http://169.254.169.254/opc/v2/instance/' with {'url': 'http://169.254.169.254/opc/v2/instance/', 'stream': False, 'allow_redirects': True, 'method': 'GET', 'timeout': 5.0, 'headers': {'User-Agent': 'Cloud-Init/24.1~7g54599148-0ubuntu1', 'Authorization': 'Bearer Oracle'}} configuration 2024-03-01 20:51:33,488 - url_helper.py[DEBUG]: Read from http://169.254.169.254/opc/v2/instance/ (200, 3067b) after 1 attempts 2024-03-01 20:51:33,488 - ephemeral.py[DEBUG]: Skip ephemeral DHCP setup, instance has connectivity to {'url': 'http://169.254.169.254/opc/v2/instance/', 'headers': {'Authorization': 'Bearer Oracle'}, 'timeout': 5} 2024-03-01 20:51:33,489 - url_helper.py[DEBUG]: [0/3] open 'http://169.254.169.254/opc/v2/instance/' with {'url': 'http://169.254.169.254/opc/v2/instance/', 'stream': False, 'allow_redirects': True, 'method': 'GET', 'headers': {'User-Agent': 'Cloud-Init/24.1~7g54599148-0ubuntu1', 'Authorization': 'Bearer Oracle'}} configuration 2024-03-01 20:51:33,500 - url_helper.py[DEBUG]: Read from http://169.254.169.254/opc/v2/instance/ (200, 3067b) after 1 attempts 2024-03-01 20:51:33,501 - util.py[DEBUG]: Writing to /run/cloud-init/cloud-id-oracle - wb: [644] 7 bytes PROBLEM: On a Noble instance using Hardware-assisted (SR-IOV) networking, this is not working. cloud-init-local.service no longer has immediate connectivity to the IMDS. Since it cannot connect, in then attempts to create an ephemeral connection to the IMDS using DHCP. It is able to obtain a DHCP lease, but then when it tries to connect to the IMDS, the call just hangs. The call has no timeout, so this results in an instance that cannot be logged into even via the serial console because cloud-init is blocking the rest of boot. A simple cloud-init workaround is to add something along the lines of `timeout=2` to https://github.com/canonical/cloud- init/blob/main/cloudinit/sources/DataSourceOracle.py#L349 . This allows cloud-init to boot. Looking at the logs, we can see that cloud- init is unable to connect to the IMDS:
[Touch-packages] [Bug 2056194] Re: Networking broken in early boot on Oracle Native instances
** Changed in: initramfs-tools (Ubuntu) Status: New => Triaged ** Summary changed: - Networking broken in early boot on Oracle Native instances + Networking broken in early boot on Oracle Native instances due to MTU settings ** Changed in: initramfs-tools (Ubuntu) Status: Triaged => Fix Committed ** Changed in: initramfs-tools (Ubuntu) Importance: Undecided => High -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/2056194 Title: Networking broken in early boot on Oracle Native instances due to MTU settings Status in cloud-images: New Status in cloud-init package in Ubuntu: New Status in initramfs-tools package in Ubuntu: Fix Committed Bug description: 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 normally isn't necessary as we boot with connectivity to the IMDS out of the box. This can be seen in the following Jammy instance using an SR-IOV NIC: 2024-03-05 14:09:05,351 - url_helper.py[DEBUG]: [0/1] open 'http://169.254.169.254/opc/v2/instance/' with {'url': 'http://169.254.169.254/opc/v2/instance/', 'stream': False, 'allow_redirects': True, 'method': 'GET', 'timeout': 5.0, 'headers': {'User-Agent' : 'Cloud-Init/23.3.3-0ubuntu0~22.04.1', 'Authorization': 'Bearer Oracle'}} configuration 2024-03-05 14:09:05,362 - url_helper.py[DEBUG]: Read from http://169.254.169.254/opc/v2/instance/ (200, 2663b) after 1 attempts 2024-03-05 14:09:05,362 - ephemeral.py[DEBUG]: Skip ephemeral DHCP setup, instance has connectivity to {'url': 'http://169.254.169.254/opc/v2/instance/', 'headers': {'Authorization': 'Bearer Oracle'}, 'timeout': 5} 2024-03-05 14:09:05,362 - url_helper.py[DEBUG]: [0/3] open 'http://169.254.169.254/opc/v2/instance/' with {'url': 'http://169.254.169.254/opc/v2/instance/', 'stream': False, 'allow_redirects': True, 'method': 'GET', 'headers': {'User-Agent': 'Cloud-Init/23 .3.3-0ubuntu0~22.04.1', 'Authorization': 'Bearer Oracle'}} configuration 2024-03-05 14:09:05,368 - url_helper.py[DEBUG]: Read from http://169.254.169.254/opc/v2/instance/ (200, 2663b) after 1 attempts Notice the "Skip ephemeral DHCP setup, instance has connectivity". This means that cloud-init has determined that it already has connectivity and doesn't need to do any additional setup to retrieve data from the IMDS. We can also see the same behavior on a Noble paravirtualized instance: 2024-03-01 20:51:33,482 - url_helper.py[DEBUG]: [0/1] open 'http://169.254.169.254/opc/v2/instance/' with {'url': 'http://169.254.169.254/opc/v2/instance/', 'stream': False, 'allow_redirects': True, 'method': 'GET', 'timeout': 5.0, 'headers': {'User-Agent': 'Cloud-Init/24.1~7g54599148-0ubuntu1', 'Authorization': 'Bearer Oracle'}} configuration 2024-03-01 20:51:33,488 - url_helper.py[DEBUG]: Read from http://169.254.169.254/opc/v2/instance/ (200, 3067b) after 1 attempts 2024-03-01 20:51:33,488 - ephemeral.py[DEBUG]: Skip ephemeral DHCP setup, instance has connectivity to {'url': 'http://169.254.169.254/opc/v2/instance/', 'headers': {'Authorization': 'Bearer Oracle'}, 'timeout': 5} 2024-03-01 20:51:33,489 - url_helper.py[DEBUG]: [0/3] open 'http://169.254.169.254/opc/v2/instance/' with {'url': 'http://169.254.169.254/opc/v2/instance/', 'stream': False, 'allow_redirects': True, 'method': 'GET', 'headers': {'User-Agent': 'Cloud-Init/24.1~7g54599148-0ubuntu1', 'Authorization': 'Bearer Oracle'}} configuration 2024-03-01 20:51:33,500 - url_helper.py[DEBUG]: Read from http://169.254.169.254/opc/v2/instance/ (200, 3067b) after 1 attempts 2024-03-01 20:51:33,501 - util.py[DEBUG]: Writing to /run/cloud-init/cloud-id-oracle - wb: [644] 7 bytes PROBLEM: On a Noble instance using Hardware-assisted (SR-IOV) networking, this is not working. cloud-init-local.service no longer has immediate connectivity to the IMDS. Since it cannot connect, in then attempts to create an ephemeral connection to the IMDS using DHCP. It is able to obtain a DHCP lease, but then when it tries to connect to the IMDS, the call just hangs. The call has no timeout, so this results in an instance that cannot be logged into even via the serial console because cloud-init is blocking the rest of boot. A simple cloud-init workaround is to add something along the lines of `timeout=2` to https://github.com/canonical/cloud- init/blob/main/cloudinit/sources/DataSourceOracle.py#L349 . This allows cloud-init to boot. Looking at the logs, we can see that cloud- init is unable to connect to the IMDS: 2024-03-05 14:23:54,836 - ephemeral.py[DEBUG]: Received dhcp lease on ens3 for 10.0.0.133/255.255.255.0 2024-03-05 14:23:54,837 -
[Touch-packages] [Bug 2056194] Re: Networking broken in early boot on Oracle Native instances
** Tags added: patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/2056194 Title: Networking broken in early boot on Oracle Native instances Status in cloud-images: New Status in cloud-init package in Ubuntu: New Status in initramfs-tools package in Ubuntu: New Bug description: 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 normally isn't necessary as we boot with connectivity to the IMDS out of the box. This can be seen in the following Jammy instance using an SR-IOV NIC: 2024-03-05 14:09:05,351 - url_helper.py[DEBUG]: [0/1] open 'http://169.254.169.254/opc/v2/instance/' with {'url': 'http://169.254.169.254/opc/v2/instance/', 'stream': False, 'allow_redirects': True, 'method': 'GET', 'timeout': 5.0, 'headers': {'User-Agent' : 'Cloud-Init/23.3.3-0ubuntu0~22.04.1', 'Authorization': 'Bearer Oracle'}} configuration 2024-03-05 14:09:05,362 - url_helper.py[DEBUG]: Read from http://169.254.169.254/opc/v2/instance/ (200, 2663b) after 1 attempts 2024-03-05 14:09:05,362 - ephemeral.py[DEBUG]: Skip ephemeral DHCP setup, instance has connectivity to {'url': 'http://169.254.169.254/opc/v2/instance/', 'headers': {'Authorization': 'Bearer Oracle'}, 'timeout': 5} 2024-03-05 14:09:05,362 - url_helper.py[DEBUG]: [0/3] open 'http://169.254.169.254/opc/v2/instance/' with {'url': 'http://169.254.169.254/opc/v2/instance/', 'stream': False, 'allow_redirects': True, 'method': 'GET', 'headers': {'User-Agent': 'Cloud-Init/23 .3.3-0ubuntu0~22.04.1', 'Authorization': 'Bearer Oracle'}} configuration 2024-03-05 14:09:05,368 - url_helper.py[DEBUG]: Read from http://169.254.169.254/opc/v2/instance/ (200, 2663b) after 1 attempts Notice the "Skip ephemeral DHCP setup, instance has connectivity". This means that cloud-init has determined that it already has connectivity and doesn't need to do any additional setup to retrieve data from the IMDS. We can also see the same behavior on a Noble paravirtualized instance: 2024-03-01 20:51:33,482 - url_helper.py[DEBUG]: [0/1] open 'http://169.254.169.254/opc/v2/instance/' with {'url': 'http://169.254.169.254/opc/v2/instance/', 'stream': False, 'allow_redirects': True, 'method': 'GET', 'timeout': 5.0, 'headers': {'User-Agent': 'Cloud-Init/24.1~7g54599148-0ubuntu1', 'Authorization': 'Bearer Oracle'}} configuration 2024-03-01 20:51:33,488 - url_helper.py[DEBUG]: Read from http://169.254.169.254/opc/v2/instance/ (200, 3067b) after 1 attempts 2024-03-01 20:51:33,488 - ephemeral.py[DEBUG]: Skip ephemeral DHCP setup, instance has connectivity to {'url': 'http://169.254.169.254/opc/v2/instance/', 'headers': {'Authorization': 'Bearer Oracle'}, 'timeout': 5} 2024-03-01 20:51:33,489 - url_helper.py[DEBUG]: [0/3] open 'http://169.254.169.254/opc/v2/instance/' with {'url': 'http://169.254.169.254/opc/v2/instance/', 'stream': False, 'allow_redirects': True, 'method': 'GET', 'headers': {'User-Agent': 'Cloud-Init/24.1~7g54599148-0ubuntu1', 'Authorization': 'Bearer Oracle'}} configuration 2024-03-01 20:51:33,500 - url_helper.py[DEBUG]: Read from http://169.254.169.254/opc/v2/instance/ (200, 3067b) after 1 attempts 2024-03-01 20:51:33,501 - util.py[DEBUG]: Writing to /run/cloud-init/cloud-id-oracle - wb: [644] 7 bytes PROBLEM: On a Noble instance using Hardware-assisted (SR-IOV) networking, this is not working. cloud-init-local.service no longer has immediate connectivity to the IMDS. Since it cannot connect, in then attempts to create an ephemeral connection to the IMDS using DHCP. It is able to obtain a DHCP lease, but then when it tries to connect to the IMDS, the call just hangs. The call has no timeout, so this results in an instance that cannot be logged into even via the serial console because cloud-init is blocking the rest of boot. A simple cloud-init workaround is to add something along the lines of `timeout=2` to https://github.com/canonical/cloud- init/blob/main/cloudinit/sources/DataSourceOracle.py#L349 . This allows cloud-init to boot. Looking at the logs, we can see that cloud- init is unable to connect to the IMDS: 2024-03-05 14:23:54,836 - ephemeral.py[DEBUG]: Received dhcp lease on ens3 for 10.0.0.133/255.255.255.0 2024-03-05 14:23:54,837 - url_helper.py[DEBUG]: [0/3] open 'http://169.254.169.254/opc/v2/instance/' with {'url': 'http://169.254.169.254/opc/v2/instance/', 'stream': False, 'allow_redirects': True, 'method': 'GET', 'timeout': 2.0, 'headers': {'User-Agent': 'Cloud-Init/24.1~7g54599148-0ubuntu1', 'Authorization': 'Bearer Oracle'}} configuration 2024-03-05 14:23:56,841 - url_helper.py[DEBUG]: Please wait 1 seconds while
[Touch-packages] [Bug 2056194] Re: Networking broken in early boot on Oracle Native instances
I've tested the patch and it fixes the issue. I can confirm the MTU settings are now correct and curl works fine. I also confirmed it allowed cloud-init to run and fully complete the boot process: https://pastebin.ubuntu.com/p/KfcP7wmjjV/ There are no cloud-init errors: https://pastebin.ubuntu.com/p/jtkTWkDGVN/ https://pastebin.ubuntu.com/p/vZSyTJ3RsH/ All I noticed was a delay / hang during dhcp probe, followed by a timeout and it worked in the first retry: https://pastebin.ubuntu.com/p/hXWKYCypXM/ Overall, everything worked well. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/2056194 Title: Networking broken in early boot on Oracle Native instances Status in cloud-images: New Status in cloud-init package in Ubuntu: New Status in initramfs-tools package in Ubuntu: New Bug description: 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 normally isn't necessary as we boot with connectivity to the IMDS out of the box. This can be seen in the following Jammy instance using an SR-IOV NIC: 2024-03-05 14:09:05,351 - url_helper.py[DEBUG]: [0/1] open 'http://169.254.169.254/opc/v2/instance/' with {'url': 'http://169.254.169.254/opc/v2/instance/', 'stream': False, 'allow_redirects': True, 'method': 'GET', 'timeout': 5.0, 'headers': {'User-Agent' : 'Cloud-Init/23.3.3-0ubuntu0~22.04.1', 'Authorization': 'Bearer Oracle'}} configuration 2024-03-05 14:09:05,362 - url_helper.py[DEBUG]: Read from http://169.254.169.254/opc/v2/instance/ (200, 2663b) after 1 attempts 2024-03-05 14:09:05,362 - ephemeral.py[DEBUG]: Skip ephemeral DHCP setup, instance has connectivity to {'url': 'http://169.254.169.254/opc/v2/instance/', 'headers': {'Authorization': 'Bearer Oracle'}, 'timeout': 5} 2024-03-05 14:09:05,362 - url_helper.py[DEBUG]: [0/3] open 'http://169.254.169.254/opc/v2/instance/' with {'url': 'http://169.254.169.254/opc/v2/instance/', 'stream': False, 'allow_redirects': True, 'method': 'GET', 'headers': {'User-Agent': 'Cloud-Init/23 .3.3-0ubuntu0~22.04.1', 'Authorization': 'Bearer Oracle'}} configuration 2024-03-05 14:09:05,368 - url_helper.py[DEBUG]: Read from http://169.254.169.254/opc/v2/instance/ (200, 2663b) after 1 attempts Notice the "Skip ephemeral DHCP setup, instance has connectivity". This means that cloud-init has determined that it already has connectivity and doesn't need to do any additional setup to retrieve data from the IMDS. We can also see the same behavior on a Noble paravirtualized instance: 2024-03-01 20:51:33,482 - url_helper.py[DEBUG]: [0/1] open 'http://169.254.169.254/opc/v2/instance/' with {'url': 'http://169.254.169.254/opc/v2/instance/', 'stream': False, 'allow_redirects': True, 'method': 'GET', 'timeout': 5.0, 'headers': {'User-Agent': 'Cloud-Init/24.1~7g54599148-0ubuntu1', 'Authorization': 'Bearer Oracle'}} configuration 2024-03-01 20:51:33,488 - url_helper.py[DEBUG]: Read from http://169.254.169.254/opc/v2/instance/ (200, 3067b) after 1 attempts 2024-03-01 20:51:33,488 - ephemeral.py[DEBUG]: Skip ephemeral DHCP setup, instance has connectivity to {'url': 'http://169.254.169.254/opc/v2/instance/', 'headers': {'Authorization': 'Bearer Oracle'}, 'timeout': 5} 2024-03-01 20:51:33,489 - url_helper.py[DEBUG]: [0/3] open 'http://169.254.169.254/opc/v2/instance/' with {'url': 'http://169.254.169.254/opc/v2/instance/', 'stream': False, 'allow_redirects': True, 'method': 'GET', 'headers': {'User-Agent': 'Cloud-Init/24.1~7g54599148-0ubuntu1', 'Authorization': 'Bearer Oracle'}} configuration 2024-03-01 20:51:33,500 - url_helper.py[DEBUG]: Read from http://169.254.169.254/opc/v2/instance/ (200, 3067b) after 1 attempts 2024-03-01 20:51:33,501 - util.py[DEBUG]: Writing to /run/cloud-init/cloud-id-oracle - wb: [644] 7 bytes PROBLEM: On a Noble instance using Hardware-assisted (SR-IOV) networking, this is not working. cloud-init-local.service no longer has immediate connectivity to the IMDS. Since it cannot connect, in then attempts to create an ephemeral connection to the IMDS using DHCP. It is able to obtain a DHCP lease, but then when it tries to connect to the IMDS, the call just hangs. The call has no timeout, so this results in an instance that cannot be logged into even via the serial console because cloud-init is blocking the rest of boot. A simple cloud-init workaround is to add something along the lines of `timeout=2` to https://github.com/canonical/cloud- init/blob/main/cloudinit/sources/DataSourceOracle.py#L349 . This allows cloud-init to boot. Looking at the logs, we can see that cloud- init is unable to connect to the IMDS: 2024-03-05
[Touch-packages] [Bug 2056194] Re: Networking broken in early boot on Oracle Native instances
Please test the attached patch. This patch adds a dhcpcd hook to the initramfs to set the interface MTU. ** Patch added: "0001-Set-interface-MTU.patch" https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2056194/+attachment/5753730/+files/0001-Set-interface-MTU.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/2056194 Title: Networking broken in early boot on Oracle Native instances Status in cloud-images: New Status in cloud-init package in Ubuntu: New Status in initramfs-tools package in Ubuntu: New Bug description: 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 normally isn't necessary as we boot with connectivity to the IMDS out of the box. This can be seen in the following Jammy instance using an SR-IOV NIC: 2024-03-05 14:09:05,351 - url_helper.py[DEBUG]: [0/1] open 'http://169.254.169.254/opc/v2/instance/' with {'url': 'http://169.254.169.254/opc/v2/instance/', 'stream': False, 'allow_redirects': True, 'method': 'GET', 'timeout': 5.0, 'headers': {'User-Agent' : 'Cloud-Init/23.3.3-0ubuntu0~22.04.1', 'Authorization': 'Bearer Oracle'}} configuration 2024-03-05 14:09:05,362 - url_helper.py[DEBUG]: Read from http://169.254.169.254/opc/v2/instance/ (200, 2663b) after 1 attempts 2024-03-05 14:09:05,362 - ephemeral.py[DEBUG]: Skip ephemeral DHCP setup, instance has connectivity to {'url': 'http://169.254.169.254/opc/v2/instance/', 'headers': {'Authorization': 'Bearer Oracle'}, 'timeout': 5} 2024-03-05 14:09:05,362 - url_helper.py[DEBUG]: [0/3] open 'http://169.254.169.254/opc/v2/instance/' with {'url': 'http://169.254.169.254/opc/v2/instance/', 'stream': False, 'allow_redirects': True, 'method': 'GET', 'headers': {'User-Agent': 'Cloud-Init/23 .3.3-0ubuntu0~22.04.1', 'Authorization': 'Bearer Oracle'}} configuration 2024-03-05 14:09:05,368 - url_helper.py[DEBUG]: Read from http://169.254.169.254/opc/v2/instance/ (200, 2663b) after 1 attempts Notice the "Skip ephemeral DHCP setup, instance has connectivity". This means that cloud-init has determined that it already has connectivity and doesn't need to do any additional setup to retrieve data from the IMDS. We can also see the same behavior on a Noble paravirtualized instance: 2024-03-01 20:51:33,482 - url_helper.py[DEBUG]: [0/1] open 'http://169.254.169.254/opc/v2/instance/' with {'url': 'http://169.254.169.254/opc/v2/instance/', 'stream': False, 'allow_redirects': True, 'method': 'GET', 'timeout': 5.0, 'headers': {'User-Agent': 'Cloud-Init/24.1~7g54599148-0ubuntu1', 'Authorization': 'Bearer Oracle'}} configuration 2024-03-01 20:51:33,488 - url_helper.py[DEBUG]: Read from http://169.254.169.254/opc/v2/instance/ (200, 3067b) after 1 attempts 2024-03-01 20:51:33,488 - ephemeral.py[DEBUG]: Skip ephemeral DHCP setup, instance has connectivity to {'url': 'http://169.254.169.254/opc/v2/instance/', 'headers': {'Authorization': 'Bearer Oracle'}, 'timeout': 5} 2024-03-01 20:51:33,489 - url_helper.py[DEBUG]: [0/3] open 'http://169.254.169.254/opc/v2/instance/' with {'url': 'http://169.254.169.254/opc/v2/instance/', 'stream': False, 'allow_redirects': True, 'method': 'GET', 'headers': {'User-Agent': 'Cloud-Init/24.1~7g54599148-0ubuntu1', 'Authorization': 'Bearer Oracle'}} configuration 2024-03-01 20:51:33,500 - url_helper.py[DEBUG]: Read from http://169.254.169.254/opc/v2/instance/ (200, 3067b) after 1 attempts 2024-03-01 20:51:33,501 - util.py[DEBUG]: Writing to /run/cloud-init/cloud-id-oracle - wb: [644] 7 bytes PROBLEM: On a Noble instance using Hardware-assisted (SR-IOV) networking, this is not working. cloud-init-local.service no longer has immediate connectivity to the IMDS. Since it cannot connect, in then attempts to create an ephemeral connection to the IMDS using DHCP. It is able to obtain a DHCP lease, but then when it tries to connect to the IMDS, the call just hangs. The call has no timeout, so this results in an instance that cannot be logged into even via the serial console because cloud-init is blocking the rest of boot. A simple cloud-init workaround is to add something along the lines of `timeout=2` to https://github.com/canonical/cloud- init/blob/main/cloudinit/sources/DataSourceOracle.py#L349 . This allows cloud-init to boot. Looking at the logs, we can see that cloud- init is unable to connect to the IMDS: 2024-03-05 14:23:54,836 - ephemeral.py[DEBUG]: Received dhcp lease on ens3 for 10.0.0.133/255.255.255.0 2024-03-05 14:23:54,837 - url_helper.py[DEBUG]: [0/3] open 'http://169.254.169.254/opc/v2/instance/' with {'url': 'http://169.254.169.254/opc/v2/instance/',
[Touch-packages] [Bug 2056194] Re: Networking broken in early boot on Oracle Native instances
** Project changed: initramfs-tools => initramfs-tools (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/2056194 Title: Networking broken in early boot on Oracle Native instances Status in cloud-images: New Status in cloud-init package in Ubuntu: New Status in initramfs-tools package in Ubuntu: New Bug description: 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 normally isn't necessary as we boot with connectivity to the IMDS out of the box. This can be seen in the following Jammy instance using an SR-IOV NIC: 2024-03-05 14:09:05,351 - url_helper.py[DEBUG]: [0/1] open 'http://169.254.169.254/opc/v2/instance/' with {'url': 'http://169.254.169.254/opc/v2/instance/', 'stream': False, 'allow_redirects': True, 'method': 'GET', 'timeout': 5.0, 'headers': {'User-Agent' : 'Cloud-Init/23.3.3-0ubuntu0~22.04.1', 'Authorization': 'Bearer Oracle'}} configuration 2024-03-05 14:09:05,362 - url_helper.py[DEBUG]: Read from http://169.254.169.254/opc/v2/instance/ (200, 2663b) after 1 attempts 2024-03-05 14:09:05,362 - ephemeral.py[DEBUG]: Skip ephemeral DHCP setup, instance has connectivity to {'url': 'http://169.254.169.254/opc/v2/instance/', 'headers': {'Authorization': 'Bearer Oracle'}, 'timeout': 5} 2024-03-05 14:09:05,362 - url_helper.py[DEBUG]: [0/3] open 'http://169.254.169.254/opc/v2/instance/' with {'url': 'http://169.254.169.254/opc/v2/instance/', 'stream': False, 'allow_redirects': True, 'method': 'GET', 'headers': {'User-Agent': 'Cloud-Init/23 .3.3-0ubuntu0~22.04.1', 'Authorization': 'Bearer Oracle'}} configuration 2024-03-05 14:09:05,368 - url_helper.py[DEBUG]: Read from http://169.254.169.254/opc/v2/instance/ (200, 2663b) after 1 attempts Notice the "Skip ephemeral DHCP setup, instance has connectivity". This means that cloud-init has determined that it already has connectivity and doesn't need to do any additional setup to retrieve data from the IMDS. We can also see the same behavior on a Noble paravirtualized instance: 2024-03-01 20:51:33,482 - url_helper.py[DEBUG]: [0/1] open 'http://169.254.169.254/opc/v2/instance/' with {'url': 'http://169.254.169.254/opc/v2/instance/', 'stream': False, 'allow_redirects': True, 'method': 'GET', 'timeout': 5.0, 'headers': {'User-Agent': 'Cloud-Init/24.1~7g54599148-0ubuntu1', 'Authorization': 'Bearer Oracle'}} configuration 2024-03-01 20:51:33,488 - url_helper.py[DEBUG]: Read from http://169.254.169.254/opc/v2/instance/ (200, 3067b) after 1 attempts 2024-03-01 20:51:33,488 - ephemeral.py[DEBUG]: Skip ephemeral DHCP setup, instance has connectivity to {'url': 'http://169.254.169.254/opc/v2/instance/', 'headers': {'Authorization': 'Bearer Oracle'}, 'timeout': 5} 2024-03-01 20:51:33,489 - url_helper.py[DEBUG]: [0/3] open 'http://169.254.169.254/opc/v2/instance/' with {'url': 'http://169.254.169.254/opc/v2/instance/', 'stream': False, 'allow_redirects': True, 'method': 'GET', 'headers': {'User-Agent': 'Cloud-Init/24.1~7g54599148-0ubuntu1', 'Authorization': 'Bearer Oracle'}} configuration 2024-03-01 20:51:33,500 - url_helper.py[DEBUG]: Read from http://169.254.169.254/opc/v2/instance/ (200, 3067b) after 1 attempts 2024-03-01 20:51:33,501 - util.py[DEBUG]: Writing to /run/cloud-init/cloud-id-oracle - wb: [644] 7 bytes PROBLEM: On a Noble instance using Hardware-assisted (SR-IOV) networking, this is not working. cloud-init-local.service no longer has immediate connectivity to the IMDS. Since it cannot connect, in then attempts to create an ephemeral connection to the IMDS using DHCP. It is able to obtain a DHCP lease, but then when it tries to connect to the IMDS, the call just hangs. The call has no timeout, so this results in an instance that cannot be logged into even via the serial console because cloud-init is blocking the rest of boot. A simple cloud-init workaround is to add something along the lines of `timeout=2` to https://github.com/canonical/cloud- init/blob/main/cloudinit/sources/DataSourceOracle.py#L349 . This allows cloud-init to boot. Looking at the logs, we can see that cloud- init is unable to connect to the IMDS: 2024-03-05 14:23:54,836 - ephemeral.py[DEBUG]: Received dhcp lease on ens3 for 10.0.0.133/255.255.255.0 2024-03-05 14:23:54,837 - url_helper.py[DEBUG]: [0/3] open 'http://169.254.169.254/opc/v2/instance/' with {'url': 'http://169.254.169.254/opc/v2/instance/', 'stream': False, 'allow_redirects': True, 'method': 'GET', 'timeout': 2.0, 'headers': {'User-Agent': 'Cloud-Init/24.1~7g54599148-0ubuntu1', 'Authorization': 'Bearer Oracle'}} configuration 2024-03-05 14:23:56,841 -