Sam Varshavchik wrote: > Kevin Fenzi writes: > >>> That's the first ln -s call in the scriptlet. >>> >>> Now, look at the second one, the one with the -f flag. >> >> Which systemd version are you looking at? > > systemd-249.11-1.fc35.src.rpm > >> bug #2074122 was just recently fixed in >> https://bodhi.fedoraproject.org/updates/FEDORA-2022-1bf06aa328 >> systemd-249.11-2.fc35 >> >> perhaps thats what you hit? > > No. As it's been pointed out, even the stock /etc/resolv.conf's comments > read that the only thing that needs to be done is to replace this symlink. > > However, as of systemd-249.11-1.fc35.src.rpm, if you have installed a manual > /etc/resolv.conf symlink that update will reinstall the symlink back to > systemd. > > I haven't looked at systemd-249.11-2.fc35, but based on its description it's > a different bug. The scriptlet reinstalls it, but then the symlink's target > is broken. From the bug: > > > Running scriptlet: systemd-resolved-249.11-1.fc35.x86_64 69/69 > '/etc/resolv.conf' → '../run/systemd/resolve/stub-resolv.conf' > > That's the symlink getting replaced. I haven't looked at the -2's scriptlet, > but I venture that the fix for that is unlikely to prevent an existing > symlink from getting replaced here. The relevant parts of the diff from -1 to -2 are: diff --git a/systemd.spec b/systemd.spec index 91e9b6d..f30f835 100644 --- a/systemd.spec +++ b/systemd.spec [...] @@ -927,7 +927,8 @@ if [ $1 -eq 0 ] ; then fi %post resolved -[ $1 -gt 1 ] && exit 0 +[ $1 -eq 1 ] || exit 0 +# Initial installation # Related to https://bugzilla.redhat.com/show_bug.cgi?id=1943263 if ls /usr/lib/systemd/libsystemd-shared-24[0-8].so &>/dev/null; then @@ -938,6 +939,9 @@ fi %systemd_post systemd-resolved.service %posttrans resolved +[ $1 -eq 1 ] || exit 0 +# Initial installation + # Create /etc/resolv.conf symlink. # We would also create it using tmpfiles, but let's do this here # too before NetworkManager gets a chance. (systemd-tmpfiles invocation above @@ -957,11 +961,11 @@ if systemctl -q is-enabled systemd-resolved.service &>/dev/null && ! systemd-analyze cat-config systemd/resolved.conf 2>/dev/null | grep -iqE '^DNSStubListener\s*=\s*(no?|false|0|off)\s*$'; then - if ! test -e /etc/resolv.conf && ! test -L /etc/resolv.conf; then - ln -sv ../run/systemd/resolve/stub-resolv.conf /etc/resolv.conf || : + if ! test -e /etc/resolv.conf; then + ln -sv ../run/systemd/resolve/stub-resolv.conf /etc/resolv.conf elif test -d /run/systemd/system/ && ! mountpoint /etc/resolv.conf &>/dev/null; then - ln -fsv ../run/systemd/resolve/stub-resolv.conf /etc/resolv.conf || : + ln -fsv ../run/systemd/resolve/stub-resolv.conf /etc/resolv.conf fi fi That's from two commits: 0c79c0a (Do not touch /etc/resolv.conf on upgrades, 2022-04-12) 5f6666c (Revert "Avoid trying to create the symlink if there's a dangling symlink already", 2022-04-12) It skips the code which touches /etc/resolv.conf except on initial install of systemd-resolved, at least, which would have prevented this issue for most folks in this thread, I believe. Looking at the f36 and rawhide branches, it looks as though the fixes were synced to rawhide but not f36. Particularly, the `[ $1 -eq 1 ] || exit 0` in %posttrans is missing from f36. I don't know if that's intentional or not. If not, it seems like parts of this bug could be waiting to bite folks on upgrade to f36. It would be ideal if someone who cares could follow-up with the systemd package maintainers and ensure that's not an omission. -- Todd
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
