I am on f36 for a few weeks now, upgraded from f34.
This is the second time this happened. A 'dnf update' runs fine but hangs at the very end, after the list of 'Veritying'. dnf (the python3 process) is in state D+ (though I could kill it).
dnf.log ends with 2022-05-31T21:32:33+1000 DDEBUG RPM transaction start. 2022-05-31T21:37:51+1000 DDEBUG RPM transaction over.
It is missing the usual final stanza, like 2022-05-16T22:21:23+1000 DDEBUG RPM transaction over. 2022-05-16T22:21:23+1000 DDEBUG timer: verify transaction: 672 ms 2022-05-16T22:21:23+1000 DDEBUG timer: transaction: 2669 ms
dnf.rpm.log ends with this interesting line 2022-05-31T21:37:06+1000 INFO '/etc/resolv.conf' -> '../run/systemd/resolve/stub-resolv.conf' and sure enough I lost connectivity which may have lead to dnf hanging. 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.
Any idea?
Am 31.05.2022 um 14:25 schrieb Eyal Lebedinsky fedora@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).
once you update the file to be a good one, then do this:
chattr +i /etc/resolv.conf (that sets the immutable bit that disallows rename, write, delete).
That should prevent anything from overwriting the file. If you need to change the file you will have to -i the file first.
It is kind of crude but useful in cases where you really don't want a file to get changed.
On Tue, May 31, 2022 at 7:26 AM Eyal Lebedinsky fedora@eyal.emu.id.au wrote:
I am on f36 for a few weeks now, upgraded from f34.
This is the second time this happened. A 'dnf update' runs fine but hangs at the very end, after the list of 'Veritying'. dnf (the python3 process) is in state D+ (though I could kill it).
dnf.log ends with 2022-05-31T21:32:33+1000 DDEBUG RPM transaction start. 2022-05-31T21:37:51+1000 DDEBUG RPM transaction over.
It is missing the usual final stanza, like 2022-05-16T22:21:23+1000 DDEBUG RPM transaction over. 2022-05-16T22:21:23+1000 DDEBUG timer: verify transaction: 672 ms 2022-05-16T22:21:23+1000 DDEBUG timer: transaction: 2669 ms
dnf.rpm.log ends with this interesting line 2022-05-31T21:37:06+1000 INFO '/etc/resolv.conf' -> '../run/systemd/resolve/stub-resolv.conf' and sure enough I lost connectivity which may have lead to dnf hanging. 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.
Any idea?
-- Eyal Lebedinsky (fedora@eyal.emu.id.au) _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@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
Roger Heflin writes:
« HTML content follows »
once you update the file to be a good one, then do this:
chattr +i /etc/resolv.conf (that sets the immutable bit that disallows rename, write, delete).
That should prevent anything from overwriting the file. If you need to change the file you will have to -i the file first.
It is kind of crude but useful in cases where you really don't want a file to get changed.
I fear that it's only a matter of time before systemd-resolved's scriptlet gets changed to remove the immutable flag on the /etc/resolv.conf symlink before clobbering it.
It keeps finding its way back on my systems, even after I uninstalled it and told it to GTFO. More and more packages keep adding it as a dependency, and that's how it gets pulled back in.
On Tue, 31 May 2022 18:38:54 -0400 Sam Varshavchik wrote:
It keeps finding its way back on my systems, even after I uninstalled it
Uninstalling is probably hopeless. I don't bother with uninstalling things like that, but disabling and masking them seems to work well, and that leaves all the files around dependencies are looking for. So far I haven't had anything get unmasked behind my back.
Tom Horsley writes:
On Tue, 31 May 2022 18:38:54 -0400 Sam Varshavchik wrote:
It keeps finding its way back on my systems, even after I uninstalled it
Uninstalling is probably hopeless. I don't bother with uninstalling things like that, but disabling and masking them seems to work well, and that leaves all the files around dependencies are looking for. So far I haven't had anything get unmasked behind my back.
In this situation masking it is insufficient. The scriptlet still runs whenever the package gets updated. And it has a history of being, shall we say, rather insistent on taking over the /etc/resolv.conf symlink.
At some point, when the annoyance factor kicks up a notch, I'll probably create an empty rpm named "systemd-resolved", version 9999, and hopefully that'll be the end of it. Perhaps, for some yucks, publish the spec file on github so that anyone can download it and easily build this reliable version of systemd-resolved by themselves.
On 31/05/2022 22.25, Eyal Lebedinsky wrote:
I am on f36 for a few weeks now, upgraded from f34.
This is the second time this happened. A 'dnf update' runs fine but hangs at the very end, after the list of 'Veritying'. dnf (the python3 process) is in state D+ (though I could kill it).
dnf.log ends with 2022-05-31T21:32:33+1000 DDEBUG RPM transaction start. 2022-05-31T21:37:51+1000 DDEBUG RPM transaction over.
It is missing the usual final stanza, like 2022-05-16T22:21:23+1000 DDEBUG RPM transaction over. 2022-05-16T22:21:23+1000 DDEBUG timer: verify transaction: 672 ms 2022-05-16T22:21:23+1000 DDEBUG timer: transaction: 2669 ms
dnf.rpm.log ends with this interesting line 2022-05-31T21:37:06+1000 INFO '/etc/resolv.conf' -> '../run/systemd/resolve/stub-resolv.conf' and sure enough I lost connectivity which may have lead to dnf hanging. 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.
Any idea?
Following help from the list (some off-list) I was encouraged to examine my whole setup and discovered that as a result of moving the machine from bare metal to a VM I actually had some old ifcfg-* files and was missing the new one. Once this was corrected things are working.
Thanks everyone.
users@lists.stg.fedoraproject.org