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