fix: ensure systemd-resolved is set by default

[tulilirockz]

Fixes: #246

[p5]

Is it best to symlink this here, or via tmpfiles?
Is /etc/resolv.conf something the user may want to change?

This may be perfectly fine - I'm just not sure of any implications of symlinking via the container build if the user wants to update the config file

---

I guess it should be fine - the symlink will just mean the changes on a running system are accessible in /run/systemd/..?

[tulilirockz]

Probably here, if there is any /etc/resolv.conf file there by default it doesnt get replaced by networkmanager or tailscale. We can iterate on this later if for whatever reason this breaks

[bsherman]

I agree it should be here (or some similarly appropriate location in the Container build). It should not be in tmpfiles since tmpfiles may override a user's change, but doing it here we default to the desired behavior (using systemd-resolved's stub config) but anyone can modify this.

[bsherman]

We probably should change this symlink however...

ln -sf ../run/systemd/resolve/stub-resolv.conf /etc/resolv.conf is how this is configured on Fedora

[tulilirockz]

It will need to be done via systemd-tmpfiles as the container build doesnt let us that.

[bsherman]

It will need to be done via systemd-tmpfiles as the container build doesnt let us that.

why?

[tulilirockz]

@bsherman When we build stuff, /etc/resolv.conf is automatically bound from the host so that we have a working network connection inside of the container. We cant override that file as it is a read-only mountpoint from podman

[bsherman]

@bsherman When we build stuff, /etc/resolv.conf is automatically bound from the host so that we have a working network connection inside of the container. We cant override that file as it is a read-only mountpoint from podman

I thought it would be something like this.

I'm quite strongly opposed to the use of tmpfiles.d for this symlink. So perhaps we need to change that flow.

It may work to follow the lead of systemd-resolved itself...
We could:

1. use a podman bind mount of the host's /etc/resolv.conf to /run/systemd/resolve/resolv.conf
2. first thing in Containerfile, create the symlink ln -sf ../run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

That should work for DNS lookups from within container, and create the symlink pointing to the desired location.
MAYBE we should not use that specific path and instead could bind mount to /tmp/host-resolv.conf but then we'd have to do a dance of setting this up once and fixing it up at the end of the build.

[bsherman]

@tulilirockz I think you've confirmed this approach is working, correct?

[tulilirockz]

Works locally, but github actions hates it.

[bsherman]

Because it seems to be mounting a systemd resolved stub: https://github.com/ublue-os/bluefin-lts/actions/runs/13571468379/job/37937333918?pr=344#step:7:157

[bsherman]

Not sure why this would work locally unless you aren't using systemd-resolved on your local build host.