debian bullseye 11 generic amd64 - static ip networking issue. dns not working until restart of networking service
I've tested a few of the debian 11 generic amd64 qcow2 images.
When we create a vm with this image with a static ip (supplied by
networking cloud-init config in an attached virtual drive), if the vm
is assigned to a vlan with no dhcp the dns client does not work
correctly until rebooted or the "networking" service is restarted.
When the vm gets set up, the ip address is assigned and dns details
are listed correctly in the /etc/network/interfaces.d/50-cloud-init.
you can ping the gateway. you can ping external ips. but dns will not
work.
Running `service networking status` shows the networking service still
waiting for dhcp, even though the host has been configured with the
correct static ip and gateway.
restarting the service instantly fixes dns.
example of networking cloud-config:
version: 2
ethernets:
eth0:
dhcp4: False
addresses:
- 172.16.0.2/24
gateway4: 172.16.0.1
nameservers:
search: [foo.bar]
addresses: [172.16.0.1]
in our setup the cloud-init config is being supplied by a "config drive"
The real issue with this is other tasks in our cloudconfig are
failing, e.g. installing packages, importing github ssh user keys etc
as dns isn't working.
Those attempts have failed, they are run once events. so will not try
again on next reboot.
recent Images tested: debian-11-generic-amd64-20220121-894.qcow2,
debian-11-generic-amd64-daily-20220223-927.qcow2
i have had no issue with this on other cloud images, eg ubuntu 20.04
LTS, almalinux 8.4 cloud image etc.
attempted workarounds:
i've tried using the bootcmd option in cloud-init config to restart
the networking service. but that seems to happen before the networking
config is written. so that didnt fix the issue.
runcmd happens too late (some tasks have already failed at that point,
package installs etc), so that isn't a great workaround
tried using the cloud-init option to manage resolvconf, but that did
not work either.
Reply to: