> Am 31.05.2022 um 14:25 schrieb Eyal Lebedinsky <fed...@eyal.emu.id.au>: > > ... > dnf.rpm.log ends with this interesting line > 2022-05-31T21:37:06+1000 INFO '/etc/resolv.conf' -> > '../run/systemd/resolve/stub-resolv.conf'
This is expected behaviour. systemd-resolved with resolv.conf linked to that stub is the default configuration and dnf update fixes an issue we had with F35 that used a static resolv.conf again. > and sure enough I lost connectivity which may have lead to dnf hanging. Well, that’s not expected behaviour. :-). It is expected to work. > Rebooting leave my network setup broken in the same way. > Restoring resolv.conf to my usual hand made file gets things going. > > This seems to happen when a kernel is updated but not at other times. > > While I can "fix" it (I keep a resolv.conf.good) when it happens, I would > rather sort it out permanently if it is a local issue. Is there a reason why you want your static resolv.conf? The very probable reason that it doesn’t work with the symbolic link is that NetworkManager doesn’t know about your Nameserver (i.e. you have a static network configuration without a name server entry or a broken DHCP set up). _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
