Configure the resolver rather than fight it #25

2026-09-14T16:45:50Z

jschoubben commented

2026-09-14 16:45:50 +00:00

Corrects the previous attempt, which wrote /etc/resolv.conf directly. On these images that path is a symlink owned by systemd-resolved, so a file written over it is either reverted or breaks the link — found by reading a running machine rather than assuming the change had taken.

The real shape is visible in resolvectl status: the machine has sensible global fallbacks, and the link carrying the default route has exactly one server, the uplink gateway. resolved will not reach for a global fallback while the link it is using has a server of its own. So one unanswered packet is one failed lookup, and under four machines pulling images at once that happens — it has ended three runs, each time long after the egress check had passed.

The uplink stays first, so the modelled path is still the one used and still the one the check proves. The others answer only when it does not.

Verified on a live machine: the link now carries three servers with the uplink first, and resolution is intact.

Corrects the previous attempt, which wrote `/etc/resolv.conf` directly. On these images that path is a symlink owned by systemd-resolved, so a file written over it is either reverted or breaks the link — found by reading a running machine rather than assuming the change had taken. The real shape is visible in `resolvectl status`: the machine has sensible global fallbacks, and the link carrying the default route has exactly one server, the uplink gateway. resolved will not reach for a global fallback while the link it is using has a server of its own. So one unanswered packet is one failed lookup, and under four machines pulling images at once that happens — it has ended three runs, each time long after the egress check had passed. The uplink stays first, so the modelled path is still the one used and still the one the check proves. The others answer only when it does not. Verified on a live machine: the link now carries three servers with the uplink first, and resolution is intact.

jschoubben added 1 commit 2026-09-14 16:45:50 +00:00

Configure the resolver rather than fight it fa5e5cb912

The first attempt wrote /etc/resolv.conf. On these images that is a symlink
owned by systemd-resolved, so the file is either reverted or the link is broken
— found by reading a running machine instead of assuming the change had worked.

The real shape shows in resolvectl: the machine has sensible global fallbacks,
and the link carrying the default route has exactly one server, the uplink
gateway. resolved will not reach a global fallback while the link has a server
of its own, so one unanswered packet is one failed lookup. Three runs have died
that way, each long after the egress check passed.

The uplink stays first, so the modelled path is still what is used and still
what the check proves. Verified on a live machine: three servers on the link,
uplink first, resolution intact.

jschoubben merged commit 8fca04f560 into main

2026-09-14 16:45:58 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/mesh-lab#25