Comment 20 for bug 1864256

(In reply to Thomas Haller from comment #11)
> Regardless whether NetworkManager did it or the user, symlinking
> /etc/resolv.conf to /var/run/NetworkManager/resolv.conf is a possible,
> sensible configuration on its own (of course not in combination with using
> systemd-resolved). I think the upgrade to Fedora 33 should only enable
> systemd-resolved if /etc/resolv.conf is a regular file. And -- as already
> gets checked -- that it has the "generated by NetworkManager` line.

Hm, we do not touch /etc/resolv.conf during upgrade if it is already a symlink, but we do enable systemd-resolved regardless. So I think that explains how users wound up in this scenario. They presumably upgraded from very old Fedora. Assuming they didn't manually configure this, it's Fedora's job to handle that. So I still think that's a Fedora bug. We ought to either (a) assume that anyone using /var/run/NetworkManager/resolv.conf is doing so due to our mistake, and migrate them to stub-resolv.conf, or (b) not enable systemd-resolved in this scenario.

Anyway, that doesn't fully explain the weird DNS configurations we're seeing.

> I find this bug report rather confusing. There are countless ways how to configure DNS (some working/sensible, some not). But what matters it the initial configuration, directly after upgrade -- and to find out what went wrong, why is it no longer working.

Well, yes, that's the problem. Clearly something else has gone wrong somewhere for both these users, but to have an actionable bug report, we need to know exactly what. These configurations are weird, and I don't see how they could have happened. Without knowing how it happened, we don't have much to go on, and certainly no evidence of another bug, and also no evidence that it is the same problem for both users.