I upgraded the openQA staging instance to Fedora 38 today. After the upgrade, an openQA service that uses openvswitch failed to run. The failure is due to this: Apr 21 19:24:20 openqa-x86-worker04.iad2.fedoraproject.org ovs-ctl[7151]: ovs-vswitchd: error while loading shared libraries: libofproto-2.17.so.0: cannot open shared object file: No such file or directory Reproducible: Always Steps to Reproduce: 1. Update from openvswitch 2.17.0-3 or earlier to openvswitch-3.0.1-1 or later 2. Try and run /usr/sbin/ovs-vswitchd 3. Actual Results: It crashes. Expected Results: It should run. The problem seems to be that in https://src.fedoraproject.org/rpms/openvswitch/c/63ef7247552afa28db7a4316e928b9b18eb61a97?branch=rawhide , the packager attempted to turn that file into an /etc/alternatives symlink. However, this doesn't work on update. When the package is updated, I see this error: Running scriptlet: openvswitch-3.1.1-1.fc38.x86_64 2/4 failed to link /usr/sbin/ovs-vswitchd -> /etc/alternatives/ovs-vswitchd: /usr/sbin/ovs-vswitchd exists and it is either not a symlink or --keep-foreign was set and link points outside /etc/alternatives that was when updating from 3.1.0 to 3.1.1, but I suspect the same has happened with every update of the package since the alternatives change was introduced. The result is that my /usr/sbin/ovs-vswitchd is still the one from openvswitch-2.17.0-3 ; now the 2.17-versioned libraries have gone away with the update to 3.x, that binary no longer runs.
Workaround is to do `rpm -e --nodeps openvswitch` then `dnf install openvswitch` (and re-enable the service if necessary).
I just hit this on an upgrade from F37 to F38. > Workaround is to do `rpm -e --nodeps openvswitch` then `dnf install openvswitch` (and re-enable the service if necessary). This might prove to be a bit tricky given that you most likely nuked the networking on the affected machine.
# rm /usr/sbin/ovs-vswitchd # /usr/sbin/update-alternatives --install /usr/sbin/ovs-vswitchd ovs-vswitchd /usr/sbin/ovs-vswitchd.nodpdk 10 and rebooting the machine (just seemed faster than trying to get NM to sort out the mess) brought back networking for me
Ah, yeah, if your remote access to the machine depends on the openvswitch-defined network that would be tricky indeed. (In my case it doesn't; the openvswitch network is used for other purposes). Thanks for the alternative recipe.
FEDORA-2023-f988565fc0 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-f988565fc0
FEDORA-2023-f988565fc0 has been pushed to the Fedora 38 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-f988565fc0` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-f988565fc0 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-4b1ec38796 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-4b1ec38796
FEDORA-2023-4b1ec38796 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-4b1ec38796` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-4b1ec38796 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
*** Bug 2210371 has been marked as a duplicate of this bug. ***
FEDORA-2023-f988565fc0 has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2023-4b1ec38796 has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.