I am experiencing a boot delay of over 2 minutes with
debian-14-genericcloud-amd64-daily on Google Compute Engine.

It would appear this url is attempting to resolve during the boot
process: http://metadata.google.internal/computeMetadata/v1/

However this socket fails to respond in a timely manner:
/run/systemd/resolve.hook/io.systemd.Network

As a workaround I can modify the boot image as such:
ln -s /dev/null /etc/systemd/system/systemd-networkd-resolve-hook.socket

But I suppose there's a better way?

Apr 20 11:30:41 i-2026 dhcpcd[738]: ens4: executing: /bin/true PREINIT
Apr 20 11:30:41 i-2026 dhcpcd[738]: ens4: executing: /bin/true CARRIER
Apr 20 11:30:41 i-2026 dhcpcd[738]: ens4: IAID 0a:00:00:26
Apr 20 11:30:41 i-2026 dhcpcd[738]: ens4: delaying IPv4 for 0.1 seconds
Apr 20 11:30:41 i-2026 dhcpcd[738]: ens4: reading lease:
/var/lib/dhcpcd/ens4.lease
Apr 20 11:30:41 i-2026 dhcpcd[738]: ens4: rebinding lease of 10.0.0.38
Apr 20 11:30:41 i-2026 dhcpcd[738]: ens4: spawned BPF ARP 10.0.0.38 on PID 745
Apr 20 11:30:41 i-2026 dhcpcd[738]: ens4: sending REQUEST (xid
0xc4838611), next in 3.2 seconds
Apr 20 11:30:41 i-2026 dhcpcd[738]: ens4: spawned BPF BOOTP on PID 746
Apr 20 11:30:41 i-2026 dhcpcd[738]: ens4: acknowledged 10.0.0.38 from
169.254.169.254
Apr 20 11:30:41 i-2026 dhcpcd[738]: ens4: leased 10.0.0.38 for 3600 seconds
Apr 20 11:30:41 i-2026 dhcpcd[738]: ens4: renew in 1800 seconds,
rebind in 3150 seconds
Apr 20 11:30:41 i-2026 dhcpcd[738]: ens4: writing lease:
/var/lib/dhcpcd/ens4.lease
Apr 20 11:30:41 i-2026 dhcpcd[738]: ens4: adding IP address
10.0.0.38/32 broadcast 10.0.0.38
Apr 20 11:30:41 i-2026 dhcpcd[738]: ens4: using Classless Static Routes
Apr 20 11:30:41 i-2026 dhcpcd[738]: ens4: adding host route to 10.0.0.1
Apr 20 11:30:41 i-2026 dhcpcd[738]: ens4: adding default route via 10.0.0.1
Apr 20 11:30:41 i-2026 dhcpcd[738]: ens4: executing: /bin/true REBOOT
Apr 20 11:30:41 i-2026 dhcpcd[738]: ens4: spawned BOOTP proxy
10.0.0.38 on PID 748
Apr 20 11:30:41 i-2026 dhcpcd[738]: control command: dhcpcd
--dumplease --ipv4only ens4
Apr 20 11:31:09 i-2026 systemd-resolved[571]: Query on hook
'/run/systemd/resolve.hook/io.systemd.Network' failed with error
'io.systemd.TimedOut', ignoring.
Apr 20 11:31:11 i-2026 systemd-resolved[571]: Query on hook
'/run/systemd/resolve.hook/io.systemd.Network' failed with error
'io.systemd.TimedOut', ignoring.
Apr 20 11:31:39 i-2026 systemd-resolved[571]: Query on hook
'/run/systemd/resolve.hook/io.systemd.Network' failed with error
'io.systemd.TimedOut', ignoring.
Apr 20 11:31:41 i-2026 systemd-resolved[571]: Query on hook
'/run/systemd/resolve.hook/io.systemd.Network' failed with error
'io.systemd.TimedOut', ignoring.
Apr 20 11:32:09 i-2026 systemd-resolved[571]: Query on hook
'/run/systemd/resolve.hook/io.systemd.Network' failed with error
'io.systemd.TimedOut', ignoring.
Apr 20 11:32:11 i-2026 systemd-resolved[571]: Query on hook
'/run/systemd/resolve.hook/io.systemd.Network' failed with error
'io.systemd.TimedOut', ignoring.
Apr 20 11:32:39 i-2026 systemd-resolved[571]: Query on hook
'/run/systemd/resolve.hook/io.systemd.Network' failed with error
'io.systemd.TimedOut', ignoring.
Apr 20 11:32:45 i-2026 systemd-resolved[571]: Query on hook
'/run/systemd/resolve.hook/io.systemd.Network' failed with error
'io.systemd.TimedOut', ignoring.
Apr 20 11:32:45 i-2026 cloud-init[732]: 2026-04-20 11:32:45,970 -
DataSourceGCE.py[WARNING]: address
"http://metadata.google.internal/computeMetadata/v1/" is not
resolvable
Apr 20 11:32:46 i-2026 systemd[1]: Finished cloud-init-local.service -
Cloud-init: Local Stage (pre-network).
Apr 20 11:32:46 i-2026 systemd[1]: Reached target network-pre.target -
Preparation for Network.

This bug has additionally been reported to Google:
https://issuetracker.google.com/u/3/issues/513847623

debian-14-genericcloud-amd64-daily uses cloud-init.  It should work, but
is not the same as Google provides.
[…]

Okay, this can't work.  cloud-init can't use dhcpcd internally and
expect this to setup something proper.  I know that Azure data source
does something similar, but only relys on IP to find stuff.

Bastian

I found a cleaner fix, override the GCE cloud-init metadata_url as
below. Since it's now an IP address and not a hostname, it avoids the
failing DNS lookups.

datasource:
  GCE:
    metadata_url: http://169.254.169.254/computeMetadata/v1/

If you use any of google's agents, you may need to add that mapping to
/etc/hosts too.

Ross

Thanks, although not a concern in this case.

I thought adding a mapping for metadata.google.internal to /etc/hosts
in the Debian cloud image might resolve it. It helps a little, but
there are still several DNS lookup timeouts, so the metadata_url
cloud-init setting seems to be the best option.