Skip to content

[action] [PR:25991] Fix DNS in containers by preserving resolv.conf symlink during image …#26535

Merged
mssonicbld merged 1 commit intosonic-net:202511from
mssonicbld:cherry/202511/25991
Apr 3, 2026
Merged

[action] [PR:25991] Fix DNS in containers by preserving resolv.conf symlink during image …#26535
mssonicbld merged 1 commit intosonic-net:202511from
mssonicbld:cherry/202511/25991

Conversation

@mssonicbld
Copy link
Copy Markdown
Collaborator

Dependency

This PR depends on sonic-net/sonic-utilities#4365. The other PR should be merged first before this one can be merged.

Why I did it

After installing SONiC 202511 from ONIE, 10 out of 15 docker containers have empty /etc/resolv.conf and no DNS resolution. This is a regression from 202412.

The Trixie base image upgrade introduced two lines in build_debian.sh that destroy the /etc/resolv.conf symlink (created by the resolvconf package) and replace it with a regular empty file:

sudo rm -f $FILESYSTEM_ROOT/etc/resolv.conf
sudo touch $FILESYSTEM_ROOT/etc/resolv.conf

This breaks the DNS propagation chain to docker containers because /etc/resolvconf/update.d/libc checks whether /etc/resolv.conf is a symlink to /run/resolvconf/resolv.conf before notifying downstream consumers (including update-libc.d/update-containers). When the symlink is missing, DHCP-obtained DNS is never propagated to containers.

Work item tracking
  • Microsoft ADO (number only):

How I did it

Replaced sudo touch with sudo ln -sf /run/resolvconf/resolv.conf to preserve the symlink that the resolvconf package expects:

sudo rm -f $FILESYSTEM_ROOT/etc/resolv.conf
sudo ln -sf /run/resolvconf/resolv.conf $FILESYSTEM_ROOT/etc/resolv.conf

This is consistent with what resolv-config.sh does at runtime (ln -sf /run/resolvconf/resolv.conf /etc/resolv.conf) and matches the behavior of all SONiC releases prior to 202511.

How to verify it

  1. Install from ONIE on a switch
  2. After boot, verify:
    # Host resolv.conf should be a symlink
    ls -la /etc/resolv.conf
    # Expected: /etc/resolv.conf -> /run/resolvconf/resolv.conf
    
    # All containers should have DNS
    for c in $(docker ps --format '{{.Names}}'); do
      echo "=== $c ==="
      docker exec $c cat /etc/resolv.conf
    done

Which release branch to backport (provide reason below if selected)

  • 202305
  • 202311
  • 202405
  • 202411
  • 202505
  • 202511

Tested branch (Please provide the tested image version)

Description for the changelog

Link to config_db schema for YANG module changes

Signed-off-by: Sonic Build Admin sonicbld@microsoft.com

A picture of a cute animal (not mandatory but encouraged)

<!--
     Please make sure you've read and understood our contributing guidelines:
     https://github.com/Azure/SONiC/blob/gh-pages/CONTRIBUTING.md

     ** Make sure all your commits include a signature generated with `git commit -s` **

     If this is a bug fix, make sure your description includes "fixes #xxxx", or
     "closes #xxxx" or "resolves #xxxx"

     Please provide the following information:
-->

#### Dependency
This PR depends on sonic-net/sonic-utilities#4365. The other PR should be merged first before this one can be merged.

#### Why I did it

After installing SONiC 202511 from ONIE, 10 out of 15 docker containers have empty `/etc/resolv.conf` and no DNS resolution. This is a regression from 202412.

The Trixie base image upgrade introduced two lines in `build_debian.sh` that destroy the `/etc/resolv.conf` symlink (created by the `resolvconf` package) and replace it with a regular empty file:

```bash
sudo rm -f $FILESYSTEM_ROOT/etc/resolv.conf
sudo touch $FILESYSTEM_ROOT/etc/resolv.conf
```

This breaks the DNS propagation chain to docker containers because `/etc/resolvconf/update.d/libc` checks whether `/etc/resolv.conf` is a symlink to `/run/resolvconf/resolv.conf` before notifying downstream consumers (including `update-libc.d/update-containers`). When the symlink is missing, DHCP-obtained DNS is never propagated to containers.

##### Work item tracking
- Microsoft ADO **(number only)**:

#### How I did it

Replaced `sudo touch` with `sudo ln -sf /run/resolvconf/resolv.conf` to preserve the symlink that the `resolvconf` package expects:

```bash
sudo rm -f $FILESYSTEM_ROOT/etc/resolv.conf
sudo ln -sf /run/resolvconf/resolv.conf $FILESYSTEM_ROOT/etc/resolv.conf
```

This is consistent with what `resolv-config.sh` does at runtime (`ln -sf /run/resolvconf/resolv.conf /etc/resolv.conf`) and matches the behavior of all SONiC releases prior to 202511.

#### How to verify it

<!--
If PR needs to be backported, then the PR must be tested against the base branch and the earliest backport release branch and provide tested image version on these two branches. For example, if the PR is requested for master, 202211 and 202012, then the requester needs to provide test results on master and 202012.
-->

1. Install from ONIE on a switch
2. After boot, verify:
   ```bash
   # Host resolv.conf should be a symlink
   ls -la /etc/resolv.conf
   # Expected: /etc/resolv.conf -> /run/resolvconf/resolv.conf

   # All containers should have DNS
   for c in $(docker ps --format '{{.Names}}'); do
     echo "=== $c ==="
     docker exec $c cat /etc/resolv.conf
   done
   ```

#### Which release branch to backport (provide reason below if selected)

<!--
- Note we only backport fixes to a release branch, *not* features!
- Please also provide a reason for the backporting below.
- e.g.
- [x] 202006
-->

- [ ] 202305
- [ ] 202311
- [ ] 202405
- [ ] 202411
- [ ] 202505
- [x] 202511

#### Tested branch (Please provide the tested image version)

<!--
- Please provide tested image version
- e.g.
- [x] 20201231.100
-->

- [ ] <!-- image version 1 -->
- [ ] <!-- image version 2 -->

#### Description for the changelog
<!--
Write a short (one line) summary that describes the changes in this
pull request for inclusion in the changelog:
-->

<!--
 Ensure to add label/tag for the feature raised. example - PR#2174 under sonic-utilities repo. where, Generic Config and Update feature has been labelled as GCU.
-->

#### Link to config_db schema for YANG module changes
<!--
Provide a link to config_db schema for the table for which YANG model
is defined
Link should point to correct section on https://github.com/Azure/sonic-buildimage/blob/master/src/sonic-yang-models/doc/Configuration.md
-->

Signed-off-by: Sonic Build Admin <sonicbld@microsoft.com>

#### A picture of a cute animal (not mandatory but encouraged)
@mssonicbld
Copy link
Copy Markdown
Collaborator Author

Original PR: #25991

@mssonicbld
Copy link
Copy Markdown
Collaborator Author

/azp run Azure.sonic-buildimage

@azure-pipelines
Copy link
Copy Markdown

Azure Pipelines successfully started running 1 pipeline(s).

@mssonicbld mssonicbld merged commit aab1a0a into sonic-net:202511 Apr 3, 2026
19 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant