Bug 9881 - systemd-resolved not setting resolv.conf link
Summary: systemd-resolved not setting resolv.conf link
Status: RESOLVED FIXED
Alias: None
Product: buildroot
Classification: Unclassified
Component: Other (show other bugs)
Version: 2017.02.1
Hardware: All Linux
: P5 normal
Target Milestone: ---
Assignee: Yann E. MORIN
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-05-17 12:46 UTC by Michael Nosthoff
Modified: 2019-10-26 17:04 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Nosthoff 2017-05-17 12:46:42 UTC
I have a configuration with Network-Manager and systemd-resolved but without systemd-networkd.

This leads to a system with an invalid resolv.conf configuration.

The built system still has this configuration from skeleton:
/etc/resolv.conf -> ../tmp/resolv.conf

systemd is not touching /etc/resolv.conf since it exists (but points to nothing.)


the systemd.mk defines this:

define SYSTEMD_INSTALL_RESOLVCONF_HOOK
	ln -sf ../run/systemd/resolve/resolv.conf \
		$(TARGET_DIR)/etc/resolv.conf
endef

But this is only used when systemd-networkd is selected. I guess this should also be done when only BR2_PACKAGE_SYSTEMD_RESOLVED is selected.
Comment 1 Carlos Santos 2019-08-11 19:13:28 UTC
In fact the symlink should be created only if BR2_PACKAGE_SYSTEMD_RESOLVED is
selected otherwise NetworkManager fails to update resolv.conf. You can test
this on QEMU with the following defconfig:

BR2_x86_64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y
BR2_TOOLCHAIN_EXTERNAL_URL="https://toolchains.bootlin.com/downloads/releases/toolchains/x86-64-core-i7/tarballs/x86-64-core-i7--glibc--bleeding-edge-2018.11-1.tar.bz2"
BR2_TOOLCHAIN_EXTERNAL_GCC_8=y
BR2_TOOLCHAIN_EXTERNAL_HEADERS_4_14=y
BR2_TOOLCHAIN_EXTERNAL_CUSTOM_GLIBC=y
BR2_TOOLCHAIN_EXTERNAL_CXX=y
BR2_TOOLCHAIN_EXTERNAL_GDB_SERVER_COPY=y
BR2_INIT_SYSTEMD=y
# BR2_TARGET_GENERIC_GETTY is not set
BR2_SYSTEM_ENABLE_NLS=y
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_VERSION=y
BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.19.16"
BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/x86_64/linux.config"
BR2_PACKAGE_NETWORK_MANAGER=y
# BR2_PACKAGE_SYSTEMD_RESOLVED is not set
BR2_TARGET_ROOTFS_EXT2=y
# BR2_TARGET_ROOTFS_TAR is not set

The start it with

qemu-system-x86_64 -M pc -m 1024 -kernel "output/images/bzImage" \
  -drive file=output/images/rootfs.ext2,if=virtio,format=raw \
  -append "root=/dev/vda console=ttyS0,115200n8 net.ifnames=0" \
  -net nic,model=virtio -net "user" -nographic -enable-kvm \
  -rtc base=utc -device virtio-rng-pci -watchdog i6300esb

Welcome to Buildroot
buildroot login: root
# ls -l /etc/resolv.conf 
lrwxrwxrwx    1 root     root            34 Aug 11 16:35 /etc/resolv.conf -> ../run/systemd/resolve/resolv.conf
# nslookup mail.google.com
nslookup: write to '127.0.0.1': Connection refused
;; connection timed out; no servers could be reached

# rm /etc/resolv.conf
# systemctl restart NetworkManager.service
# ls -l /etc/resolv.conf 
-rw-r--r--    1 root     root            50 Aug 11 19:12 /etc/resolv.conf
# nslookup mail.google.com
Server:		10.0.2.3
Address:	10.0.2.3:53

Non-authoritative answer:
mail.google.com	canonical name = googlemail.l.google.com
Name:	googlemail.l.google.com
Address: 216.58.202.197

Non-authoritative answer:
mail.google.com	canonical name = googlemail.l.google.com
Name:	googlemail.l.google.com
Address: 2800:3f0:4001:817::2005
Comment 2 Carlos Santos 2019-08-11 19:41:10 UTC
I think it's fixed by https://patchwork.ozlabs.org/patch/1145365/
Comment 3 Thomas Petazzoni 2019-10-26 17:04:33 UTC
Fixed by https://git.buildroot.org/buildroot/commit/?id=0e51737575bcfbe573c8fe156f1e4a5408aad0fa. Thanks Carlos for looking at this old issue!