Description of problem: On current CentOS Stream, engine-setup fails for me with: 2021-01-12 12:07:29,173+0200 DEBUG otopi.plugins.otopi.services.systemd plugin.execute:926 execute-output: ('/usr/bin/systemctl', 'start', 'openvswitch.service') stderr: A dependency job for openvswitch.service failed. See 'journalctl -xe' for details. journalctl -xe shows: ===================================================================== Jan 12 12:06:10 didi-centos8-engine.lab.eng.tlv2.redhat.com setroubleshoot[11212]: SELinux is preventing /usr/sbin/ovsdb-server from open access on the perf_event labeled openvswitch_t. For complete SELinux messages run: sealert -l 368c9a86-c5d6-4866-908e-26fe90c9bf0d Jan 12 12:06:10 didi-centos8-engine.lab.eng.tlv2.redhat.com setroubleshoot[11212]: SELinux is preventing /usr/sbin/ovsdb-server from open access on the perf_event labeled openvswitch_t. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that ovsdb-server should be allowed open access on perf_event labeled openvswitch_t by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'ovsdb-server' --raw | audit2allow -M my-ovsdbserver # semodule -X 300 -i my-ovsdbserver.pp ===================================================================== Running the two commands in the end seem to be enough to fix this, if you have no /etc/openvswitch/conf.db . The failure left it, owned by 'root:root', and a second attempt failed with: Starting ovsdb-server ovsdb-server: I/O error: /etc/openvswitch/conf.db: open failed (Permission denied) Removing it was enough for a next attempt to succeed. I suspect it's a new selinux policy change or something similar.
Which version of openvswitch was used in this test run?
(In reply to Dominik Holler from comment #1) > Which version of openvswitch was used in this test run? # rpm -qa | grep -E 'openv|selinux|policy' openvswitch2.11-2.11.3-74.el8.x86_64 libselinux-2.9-5.el8.i686 selinux-policy-targeted-3.14.3-59.el8.noarch checkpolicy-2.9-1.el8.x86_64 selinux-policy-3.14.3-59.el8.noarch ovirt-openvswitch-ovn-2.11-0.2020061801.el8.noarch ovirt-python-openvswitch-2.11-0.2020061801.el8.noarch python3-libselinux-2.9-5.el8.x86_64 policycoreutils-python-utils-2.9-9.el8.noarch rpm-plugin-selinux-4.14.3-4.el8.x86_64 ovirt-openvswitch-ovn-central-2.11-0.2020061801.el8.noarch ovirt-openvswitch-2.11-0.2020061801.el8.noarch libselinux-2.9-5.el8.x86_64 python3-policycoreutils-2.9-9.el8.noarch openvswitch-selinux-extra-policy-1.0-22.el8.noarch libselinux-utils-2.9-5.el8.x86_64 policycoreutils-2.9-9.el8.x86_64 python3-openvswitch2.11-2.11.3-74.el8.x86_64 ovirt-openvswitch-ovn-common-2.11-0.2020061801.el8.noarch Please note that it was not a clean system. It went through many upgrades, starting probably with CentOS 8.0/8.1 or so and many setup/cleanup cycles (including some manual fixes along the way). Didn't try yet to reproduce on a clean system. If CI uses latest Stream, it should reproduce there soon.
I'm not aware of such a failure in OST using Stream, though we don't test upgrades in any way currently. I'd suggest to ignore it until/if we get more reports
(In reply to Michal Skrivanek from comment #3) > I'm not aware of such a failure in OST using Stream, though we don't test > upgrades in any way currently. It wasn't an upgrade of oVirt itself, only OS. > I'd suggest to ignore it until/if we get more reports Fine for me. I now reverted this VM to a snapshot I took when it was on CentOS 8.2, upgraded to Stream and latest ovirt-release-master, ran engine-setup, it succeeded. Most likely the issue was either due to past breakage I introduced or to a specific sequence of updates. Closing for now.