I have verified the fix using 255.4-1ubuntu8.1 from noble-proposed. I created a LXD jammy container: root@j:~# cat /etc/os-release PRETTY_NAME="Ubuntu 22.04.4 LTS" NAME="Ubuntu" VERSION_ID="22.04" VERSION="22.04.4 LTS (Jammy Jellyfish)" VERSION_CODENAME=jammy ID=ubuntu ID_LIKE=debian HOME_URL="https://www.ubuntu.com/" SUPPORT_URL="https://help.ubuntu.com/" BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/" PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy" UBUNTU_CODENAME=jammy And then disabled the stub-resolver according to the test plan: root@j:~# mkdir -p /etc/systemd/resolved.conf.d/ root@j:~# cat > /etc/systemd/resolved.conf.d/no-stub-resolver.conf << EOF [Resolve] DNSStubListener=no EOF root@j:~# ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf root@j:~# systemctl restart systemd-resolved root@j:~# systemctl status systemd-resolved ● systemd-resolved.service - Network Name Resolution Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2024-05-22 15:10:08 UTC; 19s ago Docs: man:systemd-resolved.service(8) man:org.freedesktop.resolve1(5) https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients Main PID: 1079 (systemd-resolve) Status: "Processing requests..." Tasks: 1 (limit: 18947) Memory: 4.5M CPU: 57ms CGroup: /system.slice/systemd-resolved.service └─1079 /lib/systemd/systemd-resolved May 22 15:10:08 j systemd[1]: Starting Network Name Resolution... May 22 15:10:08 j systemd-resolved[1079]: Positive Trust Anchors: May 22 15:10:08 j systemd-resolved[1079]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7> May 22 15:10:08 j systemd-resolved[1079]: Negative trust anchors: home.arpa 10.in-addr.arpa 16.172.in-addr.arpa 17.172> May 22 15:10:08 j systemd-resolved[1079]: Using system hostname 'j'. May 22 15:10:08 j systemd[1]: Started Network Name Resolution. Then, started the upgrade (using the tarball for the reasons mentioned in test plan): root@j:~# wget http://archive.ubuntu.com/ubuntu/dists/noble-proposed/main/dist-upgrader-all/24.04.18/noble.tar.gz --2024-05-22 15:10:36-- http://archive.ubuntu.com/ubuntu/dists/noble-proposed/main/dist-upgrader-all/24.04.18/noble.tar.gz Resolving archive.ubuntu.com (archive.ubuntu.com)... 185.125.190.39, 91.189.91.82, 185.125.190.36, ... Connecting to archive.ubuntu.com (archive.ubuntu.com)|185.125.190.39|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 1274850 (1.2M) [application/x-gzip] Saving to: ‘noble.tar.gz’ noble.tar.gz 100%[================================================>] 1.21M 1.73MB/s in 0.7s 2024-05-22 15:10:37 (1.73 MB/s) - ‘noble.tar.gz’ saved [1274850/1274850] root@j:~# tar xf noble.tar.gz root@j:~# ./noble --frontend DistUpgradeViewNonInteractive [ ... ] After the upgrade was complete: root@j:~# systemctl status systemd-resolved ● systemd-resolved.service - Network Name Resolution Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; enabled; preset: enabled) Active: active (running) since Wed 2024-05-22 15:17:26 UTC; 15min ago Docs: man:systemd-resolved.service(8) man:org.freedesktop.resolve1(5) https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients Main PID: 1076 (systemd-resolve) Status: "Processing requests..." Tasks: 1 (limit: 18947) Memory: 4.6M (peak: 5.1M) CPU: 63ms CGroup: /system.slice/systemd-resolved.service └─1076 /lib/systemd/systemd-resolved May 22 15:17:26 j systemd[1]: Starting Network Name Resolution... May 22 15:17:26 j systemd-resolved[1076]: Positive Trust Anchors: May 22 15:17:26 j systemd-resolved[1076]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7> May 22 15:17:26 j systemd-resolved[1076]: Negative trust anchors: home.arpa 10.in-addr.arpa 16.172.in-addr.arpa 17.172> May 22 15:17:26 j systemd-resolved[1076]: Using system hostname 'j'. May 22 15:17:26 j systemd[1]: Started Network Name Resolution. root@j:~# cat /etc/resolv.conf # This is /run/systemd/resolve/resolv.conf managed by man:systemd-resolved(8). # Do not edit. # # This file might be symlinked as /etc/resolv.conf. If you're looking at # /etc/resolv.conf and seeing this text, you have followed the symlink. # # This is a dynamic resolv.conf file for connecting local clients directly to # all known uplink DNS servers. This file lists all configured search domains. # # Third party programs should typically not access this file directly, but only # through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a # different way, replace this symlink by a static file or a different symlink. # # See man:systemd-resolved.service(8) for details about the supported modes of # operation for /etc/resolv.conf. nameserver 10.19.111.1 nameserver fd42:3cda:638d:a9b3::1 nameserver fe80::216:3eff:fe07:85b6%29 search lxd root@j:~# apt policy systemd-resolved systemd-resolved: Installed: 255.4-1ubuntu8.1 Candidate: 255.4-1ubuntu8.1 Version table: *** 255.4-1ubuntu8.1 500 500 http://archive.ubuntu.com/ubuntu noble-proposed/main amd64 Packages 100 /var/lib/dpkg/status 255.4-1ubuntu8 500 500 http://archive.ubuntu.com/ubuntu noble/main amd64 Packages root@j:~# grep "resolv.conf" /var/log/dist-upgrade/apt-term.log Converting /etc/resolv.conf to a symlink to /run/systemd/resolve/stub-resolv.conf... cp: '/etc/resolv.conf' and '/run/systemd/resolve/stub-resolv.conf' are the same file Cannot copy /etc/resolv.conf to /run/systemd/resolve/stub-resolv.conf So, we see that (a) the user's choice to disable stub-resolver is still in place, and (b) the failed cp is non-fatal during the upgrade.