[Bug] Passing nameserver into boot_args seems to have no effect?

[Seikilos]

Describe the bug

I configured working firecracker jailed instance but passing a dns entry to boot_args has no effect.

ping google.com fails.

To Reproduce

Used below config to start jailed firecracker:

./jailer --id $VM_ID --exec-file ./firecracker --uid $USER_ID --gid $GROUP_ID --netns /var/run/netns/$NET_NS -- --config-file fc-config.json

Used this configuration for the vm:

{
  "boot-source": {
    "kernel_image_path": "./vmlinux-6.1.102",
    "boot_args": "console=ttyS0 reboot=k panic=1 pci=off ip=172.16.0.2::172.16.0.1:255.255.255.252::eth0:off:8.8.8.8",
    "initrd_path": null
  },
  "drives": [
    {
      "drive_id": "rootfs",
      "partuuid": null,
      "is_root_device": true,
      "cache_type": "Unsafe",
      "is_read_only": false,
      "path_on_host": "./ubuntu-24.04.ext4",
      "io_engine": "Sync",
      "rate_limiter": null,
      "socket": null
    }
  ],
  "machine-config": {
    "vcpu_count": 2,
    "mem_size_mib": 1024,
    "smt": false,
    "track_dirty_pages": false,
    "huge_pages": "None"
  },
  "cpu-config": null,
  "balloon": null,
  "network-interfaces": [
    {
      "iface_id": "net1",
      "guest_mac": "06:00:AC:10:00:02",
      "host_dev_name": "tap0"
    }
  ],
  "vsock": null,
  "logger": null,
  "metrics": null,
  "mmds-config": null,
  "entropy": null
}

Entered the vm and typed ping google.com

root@ubuntu-fc-uvm:~# ping google.com
ping: google.com: Temporary failure in name resolution

Pinging an IP works:

root@ubuntu-fc-uvm:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=114 time=19.0 ms

Patching the nameserver into /etc/resolf.conf works:

echo "nameserver 8.8.8.8" > /etc/resolv.conf  && ping google.com
PING google.com (172.217.168.206) 56(84) bytes of data.
64 bytes from ams16s32-in-f14.1e100.net (172.217.168.206): icmp_seq=1 ttl=114 time=18.2 ms

It appears that either I misunderstood what the advanced network config section here is doing for DNS or there might be a bug. 🤷

Expected behaviour

Passing a DNS IP via boot_args should make dns resolution work

Environment

• Firecracker version: release-v1.11.0-x86_64
• Host and guest kernel versions: vmlinux-6.1.102
• Rootfs used: unmodified ubuntu-24.04.squashfs.upstream
• Architecture: debian x64
• Any other relevant software versions: like not

Additional context

Patching resolv.conf is undesired because I plant to mount a readonly rootfs in production and having working boot_args would be great but I think I can workaround this during preparation of the rootfs.

Checks

• Have you searched the Firecracker Issues database for similar problems?
• Have you read the existing relevant Firecracker documentation?
• Are you certain the bug being reported is a Firecracker issue? => no

[s-hamann]

Network configuration via the kernel command line is not a firecracker feature but a (guest) kernel feature. If it works correctly, the kernel writes the DNS resolvers into /proc/net/pnp. To actually make use of this information, you would need to make /etc/resolv.conf a symlink to /proc/net/pnp (or otherwise get the content into resolv.conf).

Firecracker's documentation on the topic is a little thin. The kernel documentation (on nfsroot, of all things) has more information.

[kalyazin]

Hi @Seikilos . Thanks for reporting the issue. Setting the nameserver via boot_args does indeed not work for the rootfs we use. We have removed the approach from the docs: #5214 . Users would need to use alternative ways to set it, perhaps like the one @s-hamann kindly suggested. Please let us know if you believe we can do something else on our side.

[Seikilos]

@kalyazin I've been preparing the rootfs anyway so I patched resolv.conf along the way. So yes, this fixes it.
The symlink solution is something I will keep in mind.

So feel free to close this issue, or prioritise it lower, or update the documentation on this topic.
(Actually updating the docs with a small hint seams reasonable in any case :) )

[xmarcalx]

Thanks a lot @Seikilos for the feedback.
We are closing the issue considering that seems to be resolved. We updated our doc as pointed by @kalyazin to remove stale documentation!