text:
update to 4.6.0-0.okd-2021-01-23-132511 fails due to open-vm-tools already absent

Describe the bug

I am using 4.6.0-0.okd-2021-01-17-185703 that I had trouble to install due to the presence of open-vm-tools. Not that I am in that version and try to update to 4.6.0-0.okd-2021-01-23-132511 it fails because open-vm-tools is not installed... And I cannot install it since the files exist in the base FCOS image.
Version

UPI BareMetal update from 4.6.0-0.okd-2021-01-17-185703 to 4.6.0-0.okd-2021-01-23-132511
How reproducible

Install 4.6.0-0.okd-2021-01-17-185703 and try to update to 4.6.0-0.okd-2021-01-23-132511
Log bundle
relevant log:
$ oc -n openshift-machine-config-operator logs -f machine-config-daemon-rzhsl -c machine-config-daemon | head -n100                                                                                1 ↵
I0124 16:45:38.916354  361690 start.go:108] Version: machine-config-daemon-4.6.0-202006240615.p0-378-gead62052-dirty (ead62052138543eb3e19b4de493a94ed7c88b3b9)
I0124 16:45:38.918083  361690 start.go:121] Calling chroot("/rootfs")
I0124 16:45:38.918159  361690 rpm-ostree.go:261] Running captured: rpm-ostree status --json
I0124 16:45:38.941196  361690 daemon.go:226] Booted osImageURL: quay.io/openshift/okd-content@sha256:2fe2fd4d99c953d5bcf0d53b420a2012aae7fd12986dac8e757ad68f7b97030c ()
I0124 16:45:38.947676  361690 daemon.go:233] Installed Ignition binary version: 2.8.1
I0124 16:45:38.964068  361690 start.go:97] Copied self to /run/bin/machine-config-daemon on host
I0124 16:45:38.966264  361690 metrics.go:106] Registering Prometheus metrics
I0124 16:45:38.966314  361690 metrics.go:111] Starting metrics listener on 127.0.0.1:8797
I0124 16:45:38.967331  361690 update.go:1661] Starting to manage node: okd4-master-25
I0124 16:45:38.969043  361690 rpm-ostree.go:261] Running captured: rpm-ostree status
I0124 16:45:39.060393  361690 daemon.go:862] State: idle
Deployments:
* pivot://quay.io/openshift/okd-content@sha256:2fe2fd4d99c953d5bcf0d53b420a2012aae7fd12986dac8e757ad68f7b97030c
              CustomOrigin: Managed by machine-config-operator
                 Timestamp: 2021-01-17T11:43:43Z
           LayeredPackages: NetworkManager-ovs glusterfs glusterfs-fuse qemu-guest-agent

  pivot://quay.io/openshift/okd-content@sha256:95034a94e28949af41a53b9efb2fbb0651454a7c37bab002b0646e73c4721829
              CustomOrigin: Managed by machine-config-operator
                 Timestamp: 2020-12-12T05:05:37Z
           LayeredPackages: NetworkManager-ovs glusterfs glusterfs-fuse open-vm-tools
                            qemu-guest-agent
I0124 16:45:39.060414  361690 rpm-ostree.go:261] Running captured: journalctl --list-boots
I0124 16:45:39.133258  361690 daemon.go:869] journalctl --list-boots:
-1 df8f697bbf724d5f90baaab0b3cb67d1 Wed 2021-01-20 01:06:28 UTC—Wed 2021-01-20 21:44:07 UTC
 0 257cb932d75649378301841cc566a856 Wed 2021-01-20 21:45:04 UTC—Sun 2021-01-24 16:45:39 UTC
I0124 16:45:39.133288  361690 rpm-ostree.go:261] Running captured: systemctl list-units --state=failed --no-legend
I0124 16:45:39.141003  361690 daemon.go:884] systemd service state: OK
I0124 16:45:39.141018  361690 daemon.go:616] Starting MachineConfigDaemon
I0124 16:45:39.141078  361690 daemon.go:623] Enabling Kubelet Healthz Monitor
I0124 16:45:39.978541  361690 daemon.go:397] Node okd4-master-25 is part of the control plane
I0124 16:46:02.543922  361690 daemon.go:815] Current config: rendered-master-b1d5a4357e85a929594a1abca7461e3f
I0124 16:46:02.543942  361690 daemon.go:816] Desired config: rendered-master-5cb0b39837ac2039c0b99ecf28f28f66
I0124 16:46:02.551219  361690 daemon.go:1085] Validating against current config rendered-master-b1d5a4357e85a929594a1abca7461e3f
I0124 16:46:02.559145  361690 daemon.go:1093] Validated on-disk state
I0124 16:46:02.559182  361690 update.go:431] Checking Reconcilable for config rendered-master-b1d5a4357e85a929594a1abca7461e3f to rendered-master-5cb0b39837ac2039c0b99ecf28f28f66
I0124 16:46:02.585890  361690 update.go:1661] Starting update from rendered-master-b1d5a4357e85a929594a1abca7461e3f to rendered-master-5cb0b39837ac2039c0b99ecf28f28f66: &{osUpdate:false kargs:false fips:false passwd:false files:false units:false kernelType:false extensions:true}
I0124 16:46:02.587499  361690 update.go:1661] Update prepared; beginning drain
E0124 16:46:03.494607  361690 daemon.go:344] WARNING: ignoring DaemonSet-managed Pods: openshift-cluster-node-tuning-operator/tuned-9jb5f, openshift-controller-manager/controller-manager-h58q4, openshift-dns/dns-default-7r6gh, openshift-image-registry/node-ca-2hcvz, openshift-machine-config-operator/machine-config-daemon-rzhsl, openshift-machine-config-operator/machine-config-server-4c7kn, openshift-monitoring/node-exporter-6pfbc, openshift-multus/multus-admission-controller-xhw7d, openshift-multus/multus-gnqf8, openshift-multus/network-metrics-daemon-m442k, openshift-sdn/ovs-sjwcj, openshift-sdn/sdn-bp7xx, openshift-sdn/sdn-controller-97wfv
I0124 16:46:03.494626  361690 update.go:1661] drain complete
I0124 16:46:03.496523  361690 update.go:167] Successful drain took 0.907432148 seconds
I0124 16:46:03.496561  361690 update.go:1048] Updating files
I0124 16:46:03.507190  361690 update.go:1384] Writing file "/etc/pki/ca-trust/source/anchors/openshift-config-user-ca-bundle.crt"
I0124 16:46:03.537544  361690 update.go:1384] Writing file "/etc/tmpfiles.d/cleanup-cni.conf"
I0124 16:46:03.582727  361690 update.go:1384] Writing file "/etc/kubernetes/static-pod-resources/configmaps/cloud-config/ca-bundle.pem"
I0124 16:46:03.598138  361690 update.go:1384] Writing file "/usr/local/bin/configure-ovs.sh"
I0124 16:46:03.626863  361690 update.go:1384] Writing file "/etc/containers/storage.conf"
I0124 16:46:03.658734  361690 update.go:1384] Writing file "/etc/NetworkManager/dispatcher.d/90-long-hostname"
I0124 16:46:03.690555  361690 update.go:1384] Writing file "/etc/systemd/system.conf.d/10-default-env-godebug.conf"
I0124 16:46:03.716421  361690 update.go:1384] Writing file "/etc/kubernetes/static-pod-resources/etcd-member/root-ca.crt"
I0124 16:46:03.742310  361690 update.go:1384] Writing file "/etc/modules-load.d/iptables.conf"
I0124 16:46:03.768196  361690 update.go:1384] Writing file "/etc/kubernetes/kubelet-ca.crt"
I0124 16:46:03.797334  361690 update.go:1384] Writing file "/etc/systemd/system.conf.d/kubelet-cgroups.conf"
I0124 16:46:03.843969  361690 update.go:1384] Writing file "/etc/NetworkManager/conf.d/sdn.conf"
I0124 16:46:03.876697  361690 update.go:1384] Writing file "/var/lib/kubelet/config.json"
I0124 16:46:03.906074  361690 update.go:1384] Writing file "/etc/kubernetes/manifests/recycler-pod.yaml"
I0124 16:46:03.947762  361690 update.go:1384] Writing file "/etc/kubernetes/ca.crt"
I0124 16:46:03.976996  361690 update.go:1384] Writing file "/etc/sysctl.d/forward.conf"
I0124 16:46:04.003028  361690 update.go:1384] Writing file "/etc/sysctl.d/inotify.conf"
I0124 16:46:04.035532  361690 update.go:1384] Writing file "/usr/local/bin/recover-kubeconfig.sh"
I0124 16:46:04.079446  361690 update.go:1384] Writing file "/usr/local/sbin/set-valid-hostname.sh"
I0124 16:46:04.126540  361690 update.go:1384] Writing file "/etc/kubernetes/kubelet-plugins/volume/exec/.dummy"
I0124 16:46:04.187444  361690 update.go:1384] Writing file "/etc/containers/registries.conf"
I0124 16:46:04.231752  361690 update.go:1384] Writing file "/etc/crio/crio.conf.d/00-default"
I0124 16:46:04.264022  361690 update.go:1384] Writing file "/etc/containers/policy.json"
I0124 16:46:04.296120  361690 update.go:1384] Writing file "/etc/kubernetes/cloud.conf"
I0124 16:46:04.341125  361690 update.go:1384] Writing file "/etc/kubernetes/kubelet.conf"
I0124 16:46:04.383008  361690 update.go:1384] Writing file "/etc/kubernetes/static-pod-resources/haproxy/haproxy.cfg.tmpl"
I0124 16:46:04.425794  361690 update.go:1384] Writing file "/etc/kubernetes/manifests/haproxy.yaml"
I0124 16:46:04.454560  361690 update.go:1384] Writing file "/etc/kubernetes/manifests/keepalived.yaml"
I0124 16:46:04.485005  361690 update.go:1384] Writing file "/etc/kubernetes/static-pod-resources/keepalived/keepalived.conf.tmpl"
I0124 16:46:04.529204  361690 update.go:1384] Writing file "/etc/haproxy/configuration-date"
I0124 16:46:04.559569  361690 update.go:1307] Writing systemd unit dropin "10-mco-default-env.conf"
I0124 16:46:04.590043  361690 update.go:1307] Writing systemd unit dropin "mco-disabled.conf"
I0124 16:46:04.619947  361690 update.go:1307] Writing systemd unit dropin "10-mco-default-env.conf"
I0124 16:46:04.665629  361690 update.go:1342] Writing systemd unit "kubelet.service"
I0124 16:46:04.694054  361690 update.go:1270] /etc/systemd/system/multi-user.target.wants/kubelet.service already exists. Not making a new symlink
I0124 16:46:04.694071  361690 update.go:1342] Writing systemd unit "machine-config-daemon-firstboot.service"
I0124 16:46:04.737305  361690 update.go:1270] /etc/systemd/system/multi-user.target.wants/machine-config-daemon-firstboot.service already exists. Not making a new symlink
I0124 16:46:04.737354  361690 update.go:1342] Writing systemd unit "machine-config-daemon-pull.service"
I0124 16:46:04.781140  361690 update.go:1270] /etc/systemd/system/multi-user.target.wants/machine-config-daemon-pull.service already exists. Not making a new symlink
I0124 16:46:04.781156  361690 update.go:1342] Writing systemd unit "node-valid-hostname.service"
I0124 16:46:04.810331  361690 update.go:1270] /etc/systemd/system/multi-user.target.wants/node-valid-hostname.service already exists. Not making a new symlink
I0124 16:46:04.810347  361690 update.go:1342] Writing systemd unit "nodeip-configuration.service"
I0124 16:46:04.838608  361690 update.go:1270] /etc/systemd/system/multi-user.target.wants/nodeip-configuration.service already exists. Not making a new symlink
I0124 16:46:04.838751  361690 update.go:1279] Enabled openvswitch.service
I0124 16:46:04.838774  361690 update.go:1342] Writing systemd unit "ovs-configuration.service"
I0124 16:46:04.866990  361690 update.go:1270] /etc/systemd/system/multi-user.target.wants/ovs-configuration.service already exists. Not making a new symlink
I0124 16:46:04.867008  361690 update.go:1307] Writing systemd unit dropin "10-ovs-vswitchd-restart.conf"
I0124 16:46:04.894980  361690 update.go:1307] Writing systemd unit dropin "10-ovsdb-restart.conf"
I0124 16:46:04.922755  361690 update.go:1279] Enabled ovsdb-server.service
I0124 16:46:04.922769  361690 update.go:1307] Writing systemd unit dropin "10-mco-default-env.conf"
I0124 16:46:04.952292  361690 update.go:1307] Writing systemd unit dropin "mco-controlplane-nice.conf"
I0124 16:46:04.984835  361690 update.go:1307] Writing systemd unit dropin "mco-disabled.conf"
I0124 16:46:05.014445  361690 update.go:1121] Deleting stale data
I0124 16:46:05.024578  361690 update.go:1492] Writing SSHKeys at "/home/core/.ssh/authorized_keys"
I0124 16:46:05.102356  361690 controlplane.go:42] Device /sys/devices/pci0000:00/0000:00:17.0/ata3/host2/target2:0:0/2:0:0:0/block/sda already uses scheduler bfq
I0124 16:46:05.102418  361690 run.go:18] Running: nice -- ionice -c 3 oc image extract --path /:/run/mco-machine-os-content/os-content-083590241 --registry-config /var/lib/kubelet/config.json quay.io/openshift/okd-content@sha256:2fe2fd4d99c953d5bcf0d53b420a2012aae7fd12986dac8e757ad68f7b97030c
I0124 16:46:26.979008  361690 update.go:962] Applying extensions : ["update" "--uninstall" "open-vm-tools"]
I0124 16:46:27.010657  361690 update.go:375] Rolling back applied changes to OS due to error: failed to execute rpm-ostree ["update" "--uninstall" "open-vm-tools"] : exit status 1

[root@okd4-compute-201 core]# rpm-ostree "update" "--uninstall" "open-vm-tools"
error: Package/capability 'open-vm-tools' is not currently requested

Check suggestions at https://github.com/openshift/okd/issues/471#issuecomment-766348026?

Check suggestions at https://github.com/openshift/okd/issues/471#issuecomment-766348026?

I had to do something like what the update-{master,worker} scripts do. But it was not a single smooth execution and had to fight a bit to make MCO accept my version... This is because MCO updated the rendered config twice during the update process and the update process did not agree completely with the version of the rendered MachineConfig it wanted... (also rook-ceph did not help due to the PodDisruptionBudget and its heuristic for static placement of pods...).
I guess the process is "documented" in the suggestion.

I had to do something like what the update-{master,worker} scripts do. But it was not a single smooth execution and had to fight a bit to make MCO accept my version... This is because MCO updated the rendered config twice during the update process and the update process did not agree completely with the version of the rendered MachineConfig it wanted... (also rook-ceph did not help due to the PodDisruptionBudget and its heuristic for static placement of pods...).
I guess the process is "documented" in the suggestion.

@vrutkovs
The suggested solution do not work for us. We are in the same situation trying to upgrade from 4.6.0-0.okd-2021-01-17-185703 => 4.6.0-0.okd-2021-01-23-132511.
We had to manually remove the open-vm-tools package previously in order to get to release the given release (as suggested in #471).
Trying to upgrade now we are hitting this error. Trying to uninstall open-vm-tools package says it is not installed. Trying to install it again says it cannot be done due to the hardlinking issue (VGAuthService: File exists).
The I tried to use the suggested update worker/master scripts without success:

as already found out master worker rendered config was messed up in the script
The scripts are not fully working for us, the offending command NODE=$(oc get node -l node-role.kubernetes.io/worker= -o=jsonpath='{.items[*].metadata.name}') is not returning a single result

Then I tried using
# sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora{,-updates}.repo
# /run/bin/machine-config-daemon pivot quay.io/openshift/okd-content@sha256:64f1cc9663a57d3bb9cc413502c9ccc04097be2033cf726aaf535e0e7ad5b5c4
# sed -i 's;enabled=0;enabled=1;g' /etc/yum.repos.d/fedora{,-updates}.repo

and ran into the following error:
[root@okd-pg-w-01 core]# sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora{,-updates}.repo
[root@okd-pg-w-01 core]# /run/bin/machine-config-daemon pivot quay.io/openshift/okd-content@sha256:64f1cc9663a57d3bb9cc413502c9ccc04097be2033cf726aaf535e0e7ad5b5c4
I0125 06:43:55.435091  766318 run.go:18] Running: nice -- ionice -c 3 oc image extract --path /:/run/mco-machine-os-content/os-content-296672374 --registry-config /var/lib/kubelet/config.json quay.io/openshift/okd-content@sha256:64f1cc9663a57d3bb9cc413502c9ccc04097be2033cf726aaf535e0e7ad5b5c4
I0125 06:44:20.762439  766318 rpm-ostree.go:261] Running captured: rpm-ostree status --json
I0125 06:44:20.864293  766318 rpm-ostree.go:179] Previous pivot: quay.io/openshift/okd-content@sha256:2fe2fd4d99c953d5bcf0d53b420a2012aae7fd12986dac8e757ad68f7b97030c
I0125 06:44:22.782012  766318 rpm-ostree.go:216] No com.coreos.ostree-commit label found in metadata! Inspecting...
I0125 06:44:22.782053  766318 rpm-ostree.go:261] Running captured: ostree refs --repo /run/mco-machine-os-content/os-content-296672374/srv/repo
I0125 06:44:22.896930  766318 rpm-ostree.go:224] Using ref fedora/x86_64/coreos/stable
I0125 06:44:22.896977  766318 rpm-ostree.go:261] Running captured: ostree rev-parse --repo /run/mco-machine-os-content/os-content-296672374/srv/repo fedora/x86_64/coreos/stable
I0125 06:44:22.952729  766318 rpm-ostree.go:243] Executing rebase from repo path /run/mco-machine-os-content/os-content-296672374/srv/repo with customImageURL pivot://quay.io/openshift/okd-content@sha256:64f1cc9663a57d3bb9cc413502c9ccc04097be2033cf726aaf535e0e7ad5b5c4 and checksum 4a5dccf92728fd13c944805aea5e3206d9292b401b075824a76713d9aa749d52
I0125 06:44:22.952762  766318 rpm-ostree.go:261] Running captured: rpm-ostree rebase --experimental /run/mco-machine-os-content/os-content-296672374/srv/repo:4a5dccf92728fd13c944805aea5e3206d9292b401b075824a76713d9aa749d52 --custom-origin-url pivot://quay.io/openshift/okd-content@sha256:64f1cc9663a57d3bb9cc413502c9ccc04097be2033cf726aaf535e0e7ad5b5c4 --custom-origin-description Managed by machine-config-operator
error: Could not depsolve transaction; 1 problem detected:
 Problem: package NetworkManager-ovs-1:1.26.4-1.fc33.x86_64 requires openvswitch, but none of the providers can be installed
  - conflicting requests
  - nothing provides libunbound.so.8()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_acl.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_bbdev.so.0.200()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_bitratestats.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_bpf.so.0.200()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_bus_dpaa.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_bus_fslmc.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_bus_ifpga.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_bus_pci.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_bus_vdev.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_bus_vmbus.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_cfgfile.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_cmdline.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_common_cpt.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_common_dpaax.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_common_octeontx.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_common_octeontx2.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_compressdev.so.0.200()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_cryptodev.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_distributor.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_eal.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_eal.so.20.0(DPDK_20.0)(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_efd.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_ethdev.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_ethdev.so.20.0(DPDK_20.0)(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_eventdev.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_fib.so.0.200()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_flow_classify.so.0.200()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_gro.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_gso.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_hash.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_ip_frag.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_ipsec.so.0.200()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_jobstats.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_kvargs.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_latencystats.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_lpm.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_mbuf.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_mbuf.so.20.0(DPDK_20.0)(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_member.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_mempool.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_mempool.so.20.0(DPDK_20.0)(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_mempool_bucket.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_mempool_dpaa.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_mempool_dpaa2.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_mempool_octeontx.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_mempool_octeontx2.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_mempool_ring.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_mempool_stack.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_meter.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_meter.so.20.0(DPDK_20.0)(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_meter.so.20.0(EXPERIMENTAL)(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_metrics.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_net.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pci.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pdump.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pipeline.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_af_packet.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_ark.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_atlantic.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_avp.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_axgbe.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_bbdev_fpga_lte_fec.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_bbdev_null.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_bbdev_turbo_sw.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_bnx2x.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_bnxt.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_bond.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_caam_jr.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_crypto_scheduler.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_cxgbe.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_dpaa.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_dpaa2.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_dpaa2_event.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_dpaa2_sec.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_dpaa_event.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_dpaa_sec.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_dsw_event.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_e1000.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_ena.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_enetc.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_enic.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_failsafe.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_fm10k.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_hinic.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_hns3.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_i40e.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_iavf.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_ice.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_ifc.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_ixgbe.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_lio.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_memif.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_mlx5.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_netvsc.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_nfp.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_nitrox.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_null.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_null_crypto.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_octeontx.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_octeontx2.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_octeontx2_crypto.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_octeontx2_event.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_octeontx_crypto.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_octeontx_ssovf.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_octeontx_zip.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_opdl_event.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_pcap.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_qat.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_qede.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_ring.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_sfc_efx.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_skeleton_event.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_softnic.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_sw_event.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_tap.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_thunderx_nicvf.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_vdev_netvsc.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_vhost.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_virtio.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_virtio_crypto.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_vmxnet3_uio.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_port.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_rawdev.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_rawdev_dpaa2_cmdif.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_rawdev_dpaa2_qdma.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_rawdev_ioat.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_rawdev_ntb.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_rawdev_octeontx2_dma.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_rawdev_skeleton.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_rcu.so.0.200()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_reorder.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_rib.so.0.200()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_ring.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_sched.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_security.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_stack.so.0.200()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_table.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_timer.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_vhost.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_vhost.so.20.0(DPDK_20.0)(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
error: with stdout output: : error running rpm-ostree rebase --experimental /run/mco-machine-os-content/os-content-296672374/srv/repo:4a5dccf92728fd13c944805aea5e3206d9292b401b075824a76713d9aa749d52 --custom-origin-url pivot://quay.io/openshift/okd-content@sha256:64f1cc9663a57d3bb9cc413502c9ccc04097be2033cf726aaf535e0e7ad5b5c4 --custom-origin-description Managed by machine-config-operator: 0 metadata, 0 content objects imported; 0 bytes content written
Checking out tree 4a5dccf...done
Enabled rpm-md repositories: fedora-cisco-openh264 updates-archive
rpm-md repo 'fedora-cisco-openh264' (cached); generated: 2020-08-25T19:10:34Z
rpm-md repo 'updates-archive' (cached); generated: 2021-01-25T03:18:19Z
Importing rpm-md...done
Resolving dependencies...done
: exit status 1

Any suggestions?

@vrutkovs
The suggested solution do not work for us. We are in the same situation trying to upgrade from 4.6.0-0.okd-2021-01-17-185703 => 4.6.0-0.okd-2021-01-23-132511.
We had to manually remove the open-vm-tools package previously in order to get to release the given release (as suggested in #471).
Trying to upgrade now we are hitting this error. Trying to uninstall open-vm-tools package says it is not installed. Trying to install it again says it cannot be done due to the hardlinking issue (VGAuthService: File exists).
The I tried to use the suggested update worker/master scripts without success:

as already found out master worker rendered config was messed up in the script
The scripts are not fully working for us, the offending command NODE=$(oc get node -l node-role.kubernetes.io/worker= -o=jsonpath='{.items[*].metadata.name}') is not returning a single result

Then I tried using
# sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora{,-updates}.repo
# /run/bin/machine-config-daemon pivot quay.io/openshift/okd-content@sha256:64f1cc9663a57d3bb9cc413502c9ccc04097be2033cf726aaf535e0e7ad5b5c4
# sed -i 's;enabled=0;enabled=1;g' /etc/yum.repos.d/fedora{,-updates}.repo

and ran into the following error:
[root@okd-pg-w-01 core]# sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora{,-updates}.repo
[root@okd-pg-w-01 core]# /run/bin/machine-config-daemon pivot quay.io/openshift/okd-content@sha256:64f1cc9663a57d3bb9cc413502c9ccc04097be2033cf726aaf535e0e7ad5b5c4
I0125 06:43:55.435091  766318 run.go:18] Running: nice -- ionice -c 3 oc image extract --path /:/run/mco-machine-os-content/os-content-296672374 --registry-config /var/lib/kubelet/config.json quay.io/openshift/okd-content@sha256:64f1cc9663a57d3bb9cc413502c9ccc04097be2033cf726aaf535e0e7ad5b5c4
I0125 06:44:20.762439  766318 rpm-ostree.go:261] Running captured: rpm-ostree status --json
I0125 06:44:20.864293  766318 rpm-ostree.go:179] Previous pivot: quay.io/openshift/okd-content@sha256:2fe2fd4d99c953d5bcf0d53b420a2012aae7fd12986dac8e757ad68f7b97030c
I0125 06:44:22.782012  766318 rpm-ostree.go:216] No com.coreos.ostree-commit label found in metadata! Inspecting...
I0125 06:44:22.782053  766318 rpm-ostree.go:261] Running captured: ostree refs --repo /run/mco-machine-os-content/os-content-296672374/srv/repo
I0125 06:44:22.896930  766318 rpm-ostree.go:224] Using ref fedora/x86_64/coreos/stable
I0125 06:44:22.896977  766318 rpm-ostree.go:261] Running captured: ostree rev-parse --repo /run/mco-machine-os-content/os-content-296672374/srv/repo fedora/x86_64/coreos/stable
I0125 06:44:22.952729  766318 rpm-ostree.go:243] Executing rebase from repo path /run/mco-machine-os-content/os-content-296672374/srv/repo with customImageURL pivot://quay.io/openshift/okd-content@sha256:64f1cc9663a57d3bb9cc413502c9ccc04097be2033cf726aaf535e0e7ad5b5c4 and checksum 4a5dccf92728fd13c944805aea5e3206d9292b401b075824a76713d9aa749d52
I0125 06:44:22.952762  766318 rpm-ostree.go:261] Running captured: rpm-ostree rebase --experimental /run/mco-machine-os-content/os-content-296672374/srv/repo:4a5dccf92728fd13c944805aea5e3206d9292b401b075824a76713d9aa749d52 --custom-origin-url pivot://quay.io/openshift/okd-content@sha256:64f1cc9663a57d3bb9cc413502c9ccc04097be2033cf726aaf535e0e7ad5b5c4 --custom-origin-description Managed by machine-config-operator
error: Could not depsolve transaction; 1 problem detected:
 Problem: package NetworkManager-ovs-1:1.26.4-1.fc33.x86_64 requires openvswitch, but none of the providers can be installed
  - conflicting requests
  - nothing provides libunbound.so.8()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_acl.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_bbdev.so.0.200()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_bitratestats.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_bpf.so.0.200()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_bus_dpaa.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_bus_fslmc.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_bus_ifpga.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_bus_pci.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_bus_vdev.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_bus_vmbus.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_cfgfile.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_cmdline.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_common_cpt.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_common_dpaax.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_common_octeontx.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_common_octeontx2.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_compressdev.so.0.200()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_cryptodev.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_distributor.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_eal.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_eal.so.20.0(DPDK_20.0)(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_efd.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_ethdev.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_ethdev.so.20.0(DPDK_20.0)(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_eventdev.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_fib.so.0.200()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_flow_classify.so.0.200()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_gro.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_gso.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_hash.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_ip_frag.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_ipsec.so.0.200()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_jobstats.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_kvargs.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_latencystats.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_lpm.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_mbuf.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_mbuf.so.20.0(DPDK_20.0)(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_member.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_mempool.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_mempool.so.20.0(DPDK_20.0)(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_mempool_bucket.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_mempool_dpaa.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_mempool_dpaa2.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_mempool_octeontx.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_mempool_octeontx2.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_mempool_ring.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_mempool_stack.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_meter.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_meter.so.20.0(DPDK_20.0)(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_meter.so.20.0(EXPERIMENTAL)(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_metrics.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_net.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pci.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pdump.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pipeline.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_af_packet.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_ark.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_atlantic.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_avp.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_axgbe.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_bbdev_fpga_lte_fec.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_bbdev_null.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_bbdev_turbo_sw.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_bnx2x.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_bnxt.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_bond.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_caam_jr.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_crypto_scheduler.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_cxgbe.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_dpaa.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_dpaa2.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_dpaa2_event.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_dpaa2_sec.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_dpaa_event.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_dpaa_sec.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_dsw_event.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_e1000.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_ena.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_enetc.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_enic.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_failsafe.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_fm10k.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_hinic.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_hns3.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_i40e.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_iavf.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_ice.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_ifc.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_ixgbe.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_lio.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_memif.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_mlx5.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_netvsc.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_nfp.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_nitrox.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_null.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_null_crypto.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_octeontx.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_octeontx2.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_octeontx2_crypto.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_octeontx2_event.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_octeontx_crypto.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_octeontx_ssovf.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_octeontx_zip.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_opdl_event.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_pcap.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_qat.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_qede.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_ring.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_sfc_efx.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_skeleton_event.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_softnic.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_sw_event.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_tap.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_thunderx_nicvf.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_vdev_netvsc.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_vhost.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_virtio.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_virtio_crypto.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_pmd_vmxnet3_uio.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_port.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_rawdev.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_rawdev_dpaa2_cmdif.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_rawdev_dpaa2_qdma.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_rawdev_ioat.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_rawdev_ntb.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_rawdev_octeontx2_dma.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_rawdev_skeleton.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_rcu.so.0.200()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_reorder.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_rib.so.0.200()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_ring.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_sched.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_security.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_stack.so.0.200()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_table.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_timer.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_vhost.so.20.0()(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
  - nothing provides librte_vhost.so.20.0(DPDK_20.0)(64bit) needed by openvswitch-2.14.0-2.fc33.x86_64
error: with stdout output: : error running rpm-ostree rebase --experimental /run/mco-machine-os-content/os-content-296672374/srv/repo:4a5dccf92728fd13c944805aea5e3206d9292b401b075824a76713d9aa749d52 --custom-origin-url pivot://quay.io/openshift/okd-content@sha256:64f1cc9663a57d3bb9cc413502c9ccc04097be2033cf726aaf535e0e7ad5b5c4 --custom-origin-description Managed by machine-config-operator: 0 metadata, 0 content objects imported; 0 bytes content written
Checking out tree 4a5dccf...done
Enabled rpm-md repositories: fedora-cisco-openh264 updates-archive
rpm-md repo 'fedora-cisco-openh264' (cached); generated: 2020-08-25T19:10:34Z
rpm-md repo 'updates-archive' (cached); generated: 2021-01-25T03:18:19Z
Importing rpm-md...done
Resolving dependencies...done
: exit status 1

Any suggestions?

as already found out master worker rendered config was messed up in the script

Fixed

The scripts are not fully working for us, the offending command NODE=$(oc get node -l node-role.kubernetes.io/worker= -o=jsonpath='{.items[*].metadata.name}') is not returning a single result

Oh, hmm, updated to use hostname -f instead

and ran into the following error:

Check if rpm-ostree cleanup -m cleans up metadata and pivot proceeds?
Probably my bash-foo is too weak, maybe we should be using sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora.repo && sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora-updates.repo instead?

as already found out master worker rendered config was messed up in the script

Fixed

The scripts are not fully working for us, the offending command NODE=$(oc get node -l node-role.kubernetes.io/worker= -o=jsonpath='{.items[*].metadata.name}') is not returning a single result

Oh, hmm, updated to use hostname -f instead

and ran into the following error:

Check if rpm-ostree cleanup -m cleans up metadata and pivot proceeds?
Probably my bash-foo is too weak, maybe we should be using sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora.repo && sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora-updates.repo instead?

The command rpm-ostree cleanup -m succeeds, still we have no luck. What we have tried now is:
rpm-ostree cleanup -m

sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora.repo
sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora-updates.repo
sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora-updates-archive.repo
sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora-cisco-openh264.repo

/run/bin/machine-config-daemon pivot "quay.io/openshift/okd-content@sha256:2fe2fd4d99c953d5bcf0d53b420a2012aae7fd12986dac8e757ad68f7b97030c"
sed -i 's;enabled=0;enabled=1;g' /etc/yum.repos.d/fedora{,-updates}.repo

giving the following error:
[root@okd-pg-w-03 core]# rpm-ostree cleanup -m
[root@okd-pg-w-03 core]#
[root@okd-pg-w-03 core]# sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora.repo
[root@okd-pg-w-03 core]# sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora-updates.repo
[root@okd-pg-w-03 core]# sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora-updates-archive.repo
[root@okd-pg-w-03 core]# sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora-cisco-openh264.repo
[root@okd-pg-w-03 core]#
[root@okd-pg-w-03 core]# /run/bin/machine-config-daemon pivot "quay.io/openshift/okd-content@sha256:2fe2fd4d99c953d5bcf0d53b420a2012aae7fd12986dac8e757ad68f7b97030c"
I0125 09:13:29.520866    7856 run.go:18] Running: nice -- ionice -c 3 oc image extract --path /:/run/mco-machine-os-content/os-content-629531133 --registry-config /var/lib/kubelet/config.json quay.io/openshift/okd-content@sha256:2fe2fd4d99c953d5bcf0d53b420a2012aae7fd12986dac8e757ad68f7b97030c
I0125 09:13:49.599318    7856 rpm-ostree.go:261] Running captured: rpm-ostree status --json
I0125 09:13:49.642793    7856 rpm-ostree.go:179] Previous pivot: quay.io/openshift/okd-content@sha256:2fe2fd4d99c953d5bcf0d53b420a2012aae7fd12986dac8e757ad68f7b97030c
I0125 09:13:51.572609    7856 rpm-ostree.go:216] No com.coreos.ostree-commit label found in metadata! Inspecting...
I0125 09:13:51.572639    7856 rpm-ostree.go:261] Running captured: ostree refs --repo /run/mco-machine-os-content/os-content-629531133/srv/repo
I0125 09:13:51.609109    7856 rpm-ostree.go:224] Using ref fedora/x86_64/coreos/next-devel
I0125 09:13:51.609163    7856 rpm-ostree.go:261] Running captured: ostree rev-parse --repo /run/mco-machine-os-content/os-content-629531133/srv/repo fedora/x86_64/coreos/next-devel
I0125 09:13:51.633534    7856 rpm-ostree.go:243] Executing rebase from repo path /run/mco-machine-os-content/os-content-629531133/srv/repo with customImageURL pivot://quay.io/openshift/okd-content@sha256:2fe2fd4d99c953d5bcf0d53b420a2012aae7fd12986dac8e757ad68f7b97030c and checksum 14eea5296ffb7a28aff80a70c03434e8034422b0d11b47475b29530b93ab4682
I0125 09:13:51.633569    7856 rpm-ostree.go:261] Running captured: rpm-ostree rebase --experimental /run/mco-machine-os-content/os-content-629531133/srv/repo:14eea5296ffb7a28aff80a70c03434e8034422b0d11b47475b29530b93ab4682 --custom-origin-url pivot://quay.io/openshift/okd-content@sha256:2fe2fd4d99c953d5bcf0d53b420a2012aae7fd12986dac8e757ad68f7b97030c --custom-origin-description Managed by machine-config-operator
error: No enabled repositories
error: with stdout output: : error running rpm-ostree rebase --experimental /run/mco-machine-os-content/os-content-629531133/srv/repo:14eea5296ffb7a28aff80a70c03434e8034422b0d11b47475b29530b93ab4682 --custom-origin-url pivot://quay.io/openshift/okd-content@sha256:2fe2fd4d99c953d5bcf0d53b420a2012aae7fd12986dac8e757ad68f7b97030c --custom-origin-description Managed by machine-config-operator: 0 metadata, 0 content objects imported; 0 bytes content written
Checking out tree 14eea52...done
: exit status 1
[root@okd-pg-w-03 core]# sed -i 's;enabled=0;enabled=1;g' /etc/yum.repos.d/fedora{,-updates}.repo

We are not quite sure if we are using the correct pivot point "quay.io/openshift/okd-content@sha256:2fe2fd4d99c953d5bcf0d53b420a2012aae7fd12986dac8e757ad68f7b97030c"

The command rpm-ostree cleanup -m succeeds, still we have no luck. What we have tried now is:
rpm-ostree cleanup -m

sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora.repo
sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora-updates.repo
sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora-updates-archive.repo
sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora-cisco-openh264.repo

/run/bin/machine-config-daemon pivot "quay.io/openshift/okd-content@sha256:2fe2fd4d99c953d5bcf0d53b420a2012aae7fd12986dac8e757ad68f7b97030c"
sed -i 's;enabled=0;enabled=1;g' /etc/yum.repos.d/fedora{,-updates}.repo

giving the following error:
[root@okd-pg-w-03 core]# rpm-ostree cleanup -m
[root@okd-pg-w-03 core]#
[root@okd-pg-w-03 core]# sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora.repo
[root@okd-pg-w-03 core]# sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora-updates.repo
[root@okd-pg-w-03 core]# sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora-updates-archive.repo
[root@okd-pg-w-03 core]# sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora-cisco-openh264.repo
[root@okd-pg-w-03 core]#
[root@okd-pg-w-03 core]# /run/bin/machine-config-daemon pivot "quay.io/openshift/okd-content@sha256:2fe2fd4d99c953d5bcf0d53b420a2012aae7fd12986dac8e757ad68f7b97030c"
I0125 09:13:29.520866    7856 run.go:18] Running: nice -- ionice -c 3 oc image extract --path /:/run/mco-machine-os-content/os-content-629531133 --registry-config /var/lib/kubelet/config.json quay.io/openshift/okd-content@sha256:2fe2fd4d99c953d5bcf0d53b420a2012aae7fd12986dac8e757ad68f7b97030c
I0125 09:13:49.599318    7856 rpm-ostree.go:261] Running captured: rpm-ostree status --json
I0125 09:13:49.642793    7856 rpm-ostree.go:179] Previous pivot: quay.io/openshift/okd-content@sha256:2fe2fd4d99c953d5bcf0d53b420a2012aae7fd12986dac8e757ad68f7b97030c
I0125 09:13:51.572609    7856 rpm-ostree.go:216] No com.coreos.ostree-commit label found in metadata! Inspecting...
I0125 09:13:51.572639    7856 rpm-ostree.go:261] Running captured: ostree refs --repo /run/mco-machine-os-content/os-content-629531133/srv/repo
I0125 09:13:51.609109    7856 rpm-ostree.go:224] Using ref fedora/x86_64/coreos/next-devel
I0125 09:13:51.609163    7856 rpm-ostree.go:261] Running captured: ostree rev-parse --repo /run/mco-machine-os-content/os-content-629531133/srv/repo fedora/x86_64/coreos/next-devel
I0125 09:13:51.633534    7856 rpm-ostree.go:243] Executing rebase from repo path /run/mco-machine-os-content/os-content-629531133/srv/repo with customImageURL pivot://quay.io/openshift/okd-content@sha256:2fe2fd4d99c953d5bcf0d53b420a2012aae7fd12986dac8e757ad68f7b97030c and checksum 14eea5296ffb7a28aff80a70c03434e8034422b0d11b47475b29530b93ab4682
I0125 09:13:51.633569    7856 rpm-ostree.go:261] Running captured: rpm-ostree rebase --experimental /run/mco-machine-os-content/os-content-629531133/srv/repo:14eea5296ffb7a28aff80a70c03434e8034422b0d11b47475b29530b93ab4682 --custom-origin-url pivot://quay.io/openshift/okd-content@sha256:2fe2fd4d99c953d5bcf0d53b420a2012aae7fd12986dac8e757ad68f7b97030c --custom-origin-description Managed by machine-config-operator
error: No enabled repositories
error: with stdout output: : error running rpm-ostree rebase --experimental /run/mco-machine-os-content/os-content-629531133/srv/repo:14eea5296ffb7a28aff80a70c03434e8034422b0d11b47475b29530b93ab4682 --custom-origin-url pivot://quay.io/openshift/okd-content@sha256:2fe2fd4d99c953d5bcf0d53b420a2012aae7fd12986dac8e757ad68f7b97030c --custom-origin-description Managed by machine-config-operator: 0 metadata, 0 content objects imported; 0 bytes content written
Checking out tree 14eea52...done
: exit status 1
[root@okd-pg-w-03 core]# sed -i 's;enabled=0;enabled=1;g' /etc/yum.repos.d/fedora{,-updates}.repo

We are not quite sure if we are using the correct pivot point "quay.io/openshift/okd-content@sha256:2fe2fd4d99c953d5bcf0d53b420a2012aae7fd12986dac8e757ad68f7b97030c"

In my opinion the most easy way would be to somehow force reinstall open-vm-tools so that it can be cleanly removed by the update.

In my opinion the most easy way would be to somehow force reinstall open-vm-tools so that it can be cleanly removed by the update.

2fe2f is from previous stable:
$ oc adm release info --image-for=machine-os-content quay.io/openshift/okd:4.6.0-0.okd-2021-01-17-185703
quay.io/openshift/okd-content@sha256:2fe2fd4d99c953d5bcf0d53b420a2012aae7fd12986dac8e757ad68f7b97030c

The latest has 64f1..:
$ oc adm release info --image-for=machine-os-content quay.io/openshift/okd:4.6.0-0.okd-2021-01-23-132511
quay.io/openshift/okd-content@sha256:64f1cc9663a57d3bb9cc413502c9ccc04097be2033cf726aaf535e0e7ad5b5c4

In my opinion the most easy way would be to somehow force reinstall open-vm-tools so that it can be cleanly removed by the update.

#471 is about rpm-ostree unable to install the RPM when the binaries from this RPM are already written to disk (we have to do that so that bootstrap node could have open-vm-tools too).

2fe2f is from previous stable:
$ oc adm release info --image-for=machine-os-content quay.io/openshift/okd:4.6.0-0.okd-2021-01-17-185703
quay.io/openshift/okd-content@sha256:2fe2fd4d99c953d5bcf0d53b420a2012aae7fd12986dac8e757ad68f7b97030c

The latest has 64f1..:
$ oc adm release info --image-for=machine-os-content quay.io/openshift/okd:4.6.0-0.okd-2021-01-23-132511
quay.io/openshift/okd-content@sha256:64f1cc9663a57d3bb9cc413502c9ccc04097be2033cf726aaf535e0e7ad5b5c4

In my opinion the most easy way would be to somehow force reinstall open-vm-tools so that it can be cleanly removed by the update.

#471 is about rpm-ostree unable to install the RPM when the binaries from this RPM are already written to disk (we have to do that so that bootstrap node could have open-vm-tools too).

We are confused now. We are on the way from 4.6.0-0.okd-2021-01-17-185703 to latest (4.6.0-0.okd-2021-01-23-132511). Its still not working, no matter what pivot we use, the error is always that there are now repos enabled.
rpm-ostree cleanup -m

sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora.repo
sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora-updates.repo
sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora-updates-archive.repo
sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora-cisco-openh264.repo

/run/bin/machine-config-daemon pivot "quay.io/openshift/okd-content@sha256:64f1cc9663a57d3bb9cc413502c9ccc04097be2033cf726aaf535e0e7ad5b5c4"
sed -i 's;enabled=0;enabled=1;g' /etc/yum.repos.d/fedora{,-updates}.repo

We are confused now. We are on the way from 4.6.0-0.okd-2021-01-17-185703 to latest (4.6.0-0.okd-2021-01-23-132511). Its still not working, no matter what pivot we use, the error is always that there are now repos enabled.
rpm-ostree cleanup -m

sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora.repo
sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora-updates.repo
sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora-updates-archive.repo
sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora-cisco-openh264.repo

/run/bin/machine-config-daemon pivot "quay.io/openshift/okd-content@sha256:64f1cc9663a57d3bb9cc413502c9ccc04097be2033cf726aaf535e0e7ad5b5c4"
sed -i 's;enabled=0;enabled=1;g' /etc/yum.repos.d/fedora{,-updates}.repo

I personnally did not touch the repositories at all and only used the pivot command and some forcing on the MCO part.
With a lot of patience and manual modifications of the Node objets in the API I managed to make MCO accept the new state.
Some bullet points:

ssh to the machine and switch to root
use the machine-config-daemon pivot command to manually apply the new update
reboot the host
during the reboot process force the MCO state of the machine with oc edit node and forcing the current state == desired state (the final state) clean up any error message and set step as "Done"
wait for the machine to reboot and update the MCO state in the Node if it is in degraded try to fix it. Worst case edit the /etc/machine-config-daemon/currentconfig file on the host to reflect the state you actually want

I personnally did not touch the repositories at all and only used the pivot command and some forcing on the MCO part.
With a lot of patience and manual modifications of the Node objets in the API I managed to make MCO accept the new state.
Some bullet points:

ssh to the machine and switch to root
use the machine-config-daemon pivot command to manually apply the new update
reboot the host
during the reboot process force the MCO state of the machine with oc edit node and forcing the current state == desired state (the final state) clean up any error message and set step as "Done"
wait for the machine to reboot and update the MCO state in the Node if it is in degraded try to fix it. Worst case edit the /etc/machine-config-daemon/currentconfig file on the host to reflect the state you actually want

sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora-updates.repo

This disables the repo. I think I typo'd in my comment, it should be sed -i 's;enabled=0;enabled=1;g' /etc/yum.repos.d/fedora-updates.repo

sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora-updates.repo

This disables the repo. I think I typo'd in my comment, it should be sed -i 's;enabled=0;enabled=1;g' /etc/yum.repos.d/fedora-updates.repo

So that means we should activate the fedora-updates repo?

So that means we should activate the fedora-updates repo?

temporarily - yes. machine-os-content already has all necessary dependencies, however its pretty tricky to mount it, so for this one time users should enable fedora/fedora-updates to make rpm-ostree happy.
Note, that repos need to be disabled after the node is fixed - it might backfire on cluster upgrades.

temporarily - yes. machine-os-content already has all necessary dependencies, however its pretty tricky to mount it, so for this one time users should enable fedora/fedora-updates to make rpm-ostree happy.
Note, that repos need to be disabled after the node is fixed - it might backfire on cluster upgrades.

Thanks for your help. Could you please provide a clean matrix which repos should be enabled/disabled before/after the pivot call. Something like:
BEFORE
fedora ?enabled?
fedora-updates ?enabled?
[*]

AFTER
fedora ?enabled?
fedora-updates ?disabled?
[*]

Thanks for your help. Could you please provide a clean matrix which repos should be enabled/disabled before/after the pivot call. Something like:
BEFORE
fedora ?enabled?
fedora-updates ?enabled?
[*]

AFTER
fedora ?enabled?
fedora-updates ?disabled?
[*]

For pivot you need fedora and fedora-updates. After pivot its best to probably disable those, unless you're planning to install more RPMs on the host

For pivot you need fedora and fedora-updates. After pivot its best to probably disable those, unless you're planning to install more RPMs on the host

After two days we finally managed to get the update done. The essential point was to overcome the MCO trying to provision a specific pivot point. The procedure itself is very annoying, don't know how this should be done for a large cluster. In the end the last comment from @RyuunoAelia helped us.
So here is our procedure (for each node):

Set machineconfiguration.openshift.io/desiredConfig annotation for the given node to a configuration that does not exist. This will cause MCO to put the node into degraded state doing nothing as it can't reliably determine what should be done
Watch the logs of the corresponding machine-config-daemon-XXX pod until you see the degraded state is recognised
No enter the node via SSH and apply the pivot change suggested by @vrutkovs

rpm-ostree cleanup -m
sed -i 's;enabled=0;enabled=1;g' /etc/yum.repos.d/fedora.repo
sed -i 's;enabled=0;enabled=1;g' /etc/yum.repos.d/fedora-updates.repo
/run/bin/machine-config-daemon pivot "quay.io/openshift/okd-content@sha256:64f1cc9663a57d3bb9cc413502c9ccc04097be2033cf726aaf535e0e7ad5b5c4"

This will create a new pivot point on the machine into which you will have to reboot into
Before doing the reboot edit the nodes machineconfiguration.openshift.io/currentConfig annotation and already point it to the configuration you want to switch to
Then we had to overwrite the /etc/machine-config-daemon/currentconfig file (contents where taken from the target machine config) !! Watch out: there different target configs for master and worker nodes
Reboot the node
When its up, fix machineconfiguration.openshift.io/desiredConfig to the valid target config, it should now match with the machineconfiguration.openshift.io/currentConfig value

The machine-config-daemon pod will now pick up the changes. In our case, doing this on the first node, it complained about file content mismatches for some file. We patched them manually to the desired content.
Here is a list of files we had to patch:
/etc/crio/crio.conf.d/00-default
/etc/systemd/system/kubelet.service
/etc/systemd/system/machine-config-daemon-pull.service
/etc/systemd/system/nodeip-configuration.service
/etc/systemd/system/ovs-vswitchd.service.d/10-ovs-vswitchd-restart.conf

Then the node got recognised as fully done. We rebooted once again to make sure changes persist - and so they did. We saved the patched files to our bastion and re-used for patching up the other nodes during the procedure what saved a lot of time.

After two days we finally managed to get the update done. The essential point was to overcome the MCO trying to provision a specific pivot point. The procedure itself is very annoying, don't know how this should be done for a large cluster. In the end the last comment from @RyuunoAelia helped us.
So here is our procedure (for each node):

Set machineconfiguration.openshift.io/desiredConfig annotation for the given node to a configuration that does not exist. This will cause MCO to put the node into degraded state doing nothing as it can't reliably determine what should be done
Watch the logs of the corresponding machine-config-daemon-XXX pod until you see the degraded state is recognised
No enter the node via SSH and apply the pivot change suggested by @vrutkovs

rpm-ostree cleanup -m
sed -i 's;enabled=0;enabled=1;g' /etc/yum.repos.d/fedora.repo
sed -i 's;enabled=0;enabled=1;g' /etc/yum.repos.d/fedora-updates.repo
/run/bin/machine-config-daemon pivot "quay.io/openshift/okd-content@sha256:64f1cc9663a57d3bb9cc413502c9ccc04097be2033cf726aaf535e0e7ad5b5c4"

This will create a new pivot point on the machine into which you will have to reboot into
Before doing the reboot edit the nodes machineconfiguration.openshift.io/currentConfig annotation and already point it to the configuration you want to switch to
Then we had to overwrite the /etc/machine-config-daemon/currentconfig file (contents where taken from the target machine config) !! Watch out: there different target configs for master and worker nodes
Reboot the node
When its up, fix machineconfiguration.openshift.io/desiredConfig to the valid target config, it should now match with the machineconfiguration.openshift.io/currentConfig value

The machine-config-daemon pod will now pick up the changes. In our case, doing this on the first node, it complained about file content mismatches for some file. We patched them manually to the desired content.
Here is a list of files we had to patch:
/etc/crio/crio.conf.d/00-default
/etc/systemd/system/kubelet.service
/etc/systemd/system/machine-config-daemon-pull.service
/etc/systemd/system/nodeip-configuration.service
/etc/systemd/system/ovs-vswitchd.service.d/10-ovs-vswitchd-restart.conf

Then the node got recognised as fully done. We rebooted once again to make sure changes persist - and so they did. We saved the patched files to our bastion and re-used for patching up the other nodes during the procedure what saved a lot of time.

In the end I have to admit hat this was quite a tough one, especially if you consider that all we would have needed was an rpm-ostree install open-vm-tools **--force**.
Maybe it is also a good idea to make the cluster update a bit more resilient to failures, where it fails uninstalling packages that are already no more present.

In the end I have to admit hat this was quite a tough one, especially if you consider that all we would have needed was an rpm-ostree install open-vm-tools **--force**.
Maybe it is also a good idea to make the cluster update a bit more resilient to failures, where it fails uninstalling packages that are already no more present.

@vrutkovs & @RyuunoAelia still thanks for your help.

@vrutkovs & @RyuunoAelia still thanks for your help.

Maybe it is also a good idea to make the cluster update a bit more resilient to failures, when it fails uninstalling packages that are already no more present.

Yeah, sorry about that, I'm surprised we didn't this on our CI - we'll work on improving that.

Maybe it is also a good idea to make the cluster update a bit more resilient to failures, when it fails uninstalling packages that are already no more present.

Yeah, sorry about that, I'm surprised we didn't this on our CI - we'll work on improving that.

authors: RyuunoAelia holgerstolzenberg vrutkovs

repo: openshift/okd


text:
Bug 1815816: add 2 min retry on create build existing pod wrong owner (allow for GC)

/assign @adambkaplan
@bparees FYI in case you have cycles given your historical expertise

would it be simpler to just always retry creating the new build pod for 2 minutes before giving up?
the case where an old pod exists and should not and will not be cleaned up automatically should be exceedingly rare, i'm ok w/ someone having to wait 2 minutes to be told their build can't proceed under those circumstances.

would it be simpler to just always retry creating the new build pod for 2 minutes before giving up?
the case where an old pod exists and should not and will not be cleaned up automatically should be exceedingly rare, i'm ok w/ someone having to wait 2 minutes to be told their build can't proceed under those circumstances.

Are you saying we should remove the existing logic that tries to use the pod if the owner ref matches?
If not, sorry, I'll need some more clarification.  Thanks.

Are you saying we should remove the existing logic that tries to use the pod if the owner ref matches?

no, just saying if a pod exists that does not have the right ownerref, let's go into a retry for 2 mins, instead of immediately aborting.  We can just retry based on the age (Creation time) of the build resource, rather than having to muck w/ adding new annotations to resources to track timestamps.
unless i'm not fully understanding the failure scenario here?

Are you saying we should remove the existing logic that tries to use the pod if the owner ref matches?

no, just saying if a pod exists that does not have the right ownerref, let's go into a retry for 2 mins, instead of immediately aborting. We can just retry based on the age (Creation time) of the build resource, rather than having to muck w/ adding new annotations to resources to track timestamps.
unless i'm not fully understanding the failure scenario here?

ok working off of the build creation time does seem sufficient and much less complicated than the separate annotation
I'll re-work based on that and we can go from there.
thanks

update pushed @bparees - annotation removed and creation timestamp used

/approve
it looks reasonable to me, but will let @adambkaplan give it a final review.

nits addressed @adambkaplan thanks PTAL

source: gharchive/pull-request

authors: bparees gabemontero

repo: openshift/openshift-controller-manager

license_type: permissive

license_source: github-api


text:
Disable rhsm while running hostpkg checks

Also, don't forget to bind mount the host's /var/lib/rpm

@rhdedgar gave 👍 in stg PR #2164

repo: openshift/openshift-tools


text:
Set form definition for binding parameters.

Form definition for bind parameters were not being set, rendering input fields out of order set by brokers.

 (8) Bind Parameters

@jeff-phillips-18 FYI, we should also use the form definition when we show bind parameters

authors: cfchase spadgett

repo: openshift/origin-web-catalog


text:
OCM-5085 | fix: lower mapAZcreated to 1

https://issues.redhat.com/browse/OCM-5085

/test coverage

@davidleerh 🙏 Test passed

repo: openshift/rosa


text:
Make launchpad-templates use Dockerfile instead of ConfigMap for nginx

Add nginx conf file (extracted from the existing ConfigMap)
Add a Dockerfile for building the nginx image.
Add a CI script to build the Docker Image.
Add a nginx runner script.

Could you explain what this PR is about exactly @aditya-konarde ?

Hi Tako, we are trying to unify our approach to using nginx across openshift.io and the agreement was we'd prefer to bake nginx.conf in the image rather than use configMap (configMap is troublesome because there are no triggers in OpenShift for CM change, so config change will not update the running app..)
Aditya picked up the task of the unification.
@aditya-konarde You will also need to fix the OpenShift template and remove the configmap

Ok @vpavlin , but then how are we supposed to run these things locally on Minishift?

@quintesse The CI build script will also push the image to the devshift registry, similar to the other launchpad images.
Also, discussed with @vpavlin and we need to change the template for launchpad-nginx to use this image instead of the configmap. [WIP].

You can build the nginx image locally or you can pull it from registry.devshift.net (it's public since couple weeks back).

You can build the nginx image locally or you can pull it from registry.devshift.net

Yeah, for a moment I thought you might have to always build it locally. But as long as it's available publicly it's okay.
Marking it as "changes needed" so nobody merges it accidentally.

@vpavlin @quintesse updated. Please review.

@aditya-konarde it looks okay, but we can't merge this until this new image has been accepted on the centos.org CI build server and an image has actually been built. Because without that this template will fail (for people who don't build things locally).

@aditya-konarde actually to expand on what I said before. Perhaps what we should do is split this into 2 separate PRs. One that contains the CICO script and the Dockerfiles etc so the image can be built, which we can merge immediately. And the other that contains the changes to the template which we will merge the moment the image is available in the registry.
Sounds like a plan?

@aditya-konarde it looks okay, but we can't merge this until this new image has been accepted on the centos.org CI build server and an image has actually been built. Because without that this template will fail (for people who don't build things locally).

I agree.

@aditya-konarde actually to expand on what I said before. Perhaps what we should do is split this into 2 separate PRs. One that contains the CICO script and the Dockerfiles etc so the image can be built, which we can merge immediately. And the other that contains the changes to the template which we will merge the moment the image is available in the registry.
Sounds like a plan?

Sounds good. One other way to do this would also be to build and push the image to the devshift registry once, and then merge this PR. @vpavlin : thoughts?

@aditya-konarde Please remove the volumes block as well: https://github.com/openshiftio/launchpad-templates/pull/26/files#diff-605327b86e0de8a02c3c4f36f50268e6R63
@quintesse Would it be a big deal if the repo is broken for couple minutes? (merge -> build -> push -> deploy -> validate -> if failed, fix and go again:) ). If not a bug deal, I'd say let's merge it as is - it's not going to break prod (that depends on specific commit hash), so the only potential issue is broken stage (which is fine) and local experience from master (guess that's not going to kill anyone:) ).

We still need to update almighty-jobs job before we merge this, btw..

@vpavlin Removed the volumes block. Also, sent out a PR to update almighty-jobs here

@quintesse If you are ok with the approach, we can merge https://github.com/almighty/almighty-jobs/pull/283/files, then merge this PR and then observe some awesomeness (with all fingers crossed;))

@vpavlin ok, we can do it that way. We can always revert if it takes more than a couple of minutes (it always does ;) )

So I'd say let's do it tomorrow morning so that @aditya-konarde has time to fix all he broke:-P

Ok, I manually merged all the stuff that had to do with CICO. Mainly because we had already added a scripts folder of our own in the meantime which was conflicting. So I moved the CICO files to a new cico folder (except for the build script and the Dockerfile) which is also cleaner IMO.
We can now merge the almighty-jobs PR, wait for the image to be built and merge the rest of the changes (which aren't many).

So this issue can be closed now?

No, we're not done yet :)

WHen do we do this @vpavlin @aditya-konarde ?

@quintesse We fixed this PR, so...Merging in your absence:)

Btw, @vpavlin @aditya-konarde , why is this nginx image pushed to a different registry than the rest of the images? The other launchpad images are all on Docker Hub.

authors: aditya-konarde gastaldi quintesse vpavlin

repo: openshiftio/launchpad-templates


text:
Author corrections

Small fix of author name and author list.

merged, thanks!

authors: jtrmal staffanru

repo: openslr-org/openslr


text:
support user password login ssh

fixed: #119

This change is

Codecov Report

Merging #129 (385f70d) into master (c7bb427) will decrease coverage by 2.44%.
The diff coverage is 38.66%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
Additional details and impacted files

Files Changed
Coverage Δ

src/session.rs
60.39% <0.00%> (-14.92%)
:arrow_down:

src/builder.rs
70.93% <52.72%> (-5.64%)
:arrow_down:

@baoyachi didn't you accidentally delete the repository?

authors: NobodyXu baoyachi codecov-commenter jonhoo

repo: openssh-rust/openssh


text:
64-bit build of 1.0.2h fails under Windows

Windows 10
Activestate Perl
VC 2014 and ml64 assembler
perl Configure VC-WIN64A
ms\do_win64a
nmake -f ms\ntdll.mak

fails when assembling x86_64cpuid.asm with a host of A2071:initializer magnitude too large for specified size errors. This apparently is not a new issue as it looks like a manifestation of https://rt.openssl.org/Ticket/Display.html?id=2963 -- applying the suggested patch to crypto/x86_64cpuid.pl (changing OUT to FD) certainly fixes things.
Should this "fix" not be applied to the 1.0.2 branch? Or are these errors indicative of something else and all this is doing is patching the cracks??

Please try using the nasm assembler instead of ml64. Nasm is now our only supported assembler.

Hmm, from INSTALL.W64:

You will need Microsoft Platform SDK, available for download at
http://www.microsoft.com/msdownload/platformsdk/sdkupdate/. As per
April 2005 Platform SDK is equipped with Win64 compilers, as well
as assemblers, but it might change in the future.

which is why I was using ml64.
With nasm, ms\do_win64a produces:
>perl util\mkfiles.pl  1>MINFO
>cmd /c "nasm -f win64 -v"  1>NUL 2>&1
>if 0 NEQ 0 goto ml64
>perl ms\uplink-x86_64.pl nasm  1>ms\uptable.asm
>nasm -f win64 -o ms\uptable.obj ms\uptable.asm
ms\uptable.asm:17: warning: absolute address can not be RIP-relative
ms\uptable.asm:24: warning: absolute address can not be RIP-relative
ms\uptable.asm:37: warning: absolute address can not be RIP-relative
ms\uptable.asm:44: warning: absolute address can not be RIP-relative
ms\uptable.asm:57: warning: absolute address can not be RIP-relative
ms\uptable.asm:64: warning: absolute address can not be RIP-relative
ms\uptable.asm:77: warning: absolute address can not be RIP-relative
...

with or without patching crypto/x86_64cpuid.pl.

Looks like a problem for @dot-asm

If your nasm version is 2.12.02, then it seems to be a nasm bug. I can confirm that in this case the warning can be safely ignored, as binary generated by 2.12.02 is identical to binary generated by 2.12.01. In other words, ignore it now for 2.12.02 and we'll see how nasm evolves...

Not a peep after @dot-asm's comment.  I assume this is resolved.  If not, please feel free to reopen.

source: gharchive/issue

authors: dbrnz dot-asm levitte mattcaswell

repo: openssl/openssl


text:
Question regarding TLSv1.3 Ciphers

As per Manual page "https://www.openssl.org/docs/man1.1.1/man1/ciphers.html", 5 ciphers are listed under TLS v1.3 cipher suites but the command shows only 3 cipher suites. curious to know whether
TLS_AES_128_GCM_SHA256                     TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384                     TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256               TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_CCM_SHA256                     TLS_AES_128_CCM_SHA256
TLS_AES_128_CCM_8_SHA256                   TLS_AES_128_CCM_8_SHA256
 sh-5.0# openssl
OpenSSL> version
OpenSSL 1.1.1k  25 Mar 2021
OpenSSL> ciphers -s -tls1_3
TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256
OpenSSL>

I am able to stop TLSv1.2 ciphers using the convention of "!" but unable to stop TLSv1.3 ciphers. so want to if i have to use any extra options. Please help
 sh-5.0# openssl
OpenSSL> version
OpenSSL 1.1.1k  25 Mar 2021
OpenSSL> quit
sh-5.0# openssl ciphers -v -s 'ALL:!TLS_AES_256_GCM_SHA384:!TLS_CHACHA20_POLY1305_SHA256:!TLS_AES_128_GCM_SHA256' |grep "TLSv1.3"
TLS_AES_256_GCM_SHA384  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(256) Mac=AEAD
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any      Au=any  Enc=CHACHA20/POLY1305(256) Mac=AEAD
TLS_AES_128_GCM_SHA256  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(128) Mac=AEAD
sh-5.0#

You need to use the -ciphersuites option to specify the list of TLSv1.3 ciphers to use.

Issue-1:
How to see the list of all 5 ciphers of TLSv1.3 shown in manual page?
Issue-2: If a customer wants to customize the ciphers allowed at openssl (server side), what is the command ? Are the commands different for different TLS Versions.
sh-5.0# openssl ciphers -v -ciphersuites 'ALL:!TLS_CHACHA20_POLY1305_SHA256'
Error setting TLSv1.3 ciphersuites
2801742928:error:1426E0B9:SSL routines:ciphersuite_cb:no cipher match:../openssl-1.1.1k/ssl/ssl_ciph.c:1294:
sh-5.0#

For TLSv1.2 we used the below command to hide the cipher at server side. Do we have a similar command for TLSv1.3? Rather do we have a common command for TLSv1.1, TLSv1.2 and TLSv1.3.
sh-5.0# openssl ciphers -v -s 'ALL:!ECDHE-RSA-CHACHA20-POLY1305' |grep "ECDHE-RSA-CHACHA20-POLY1305"
sh-5.0#

Issue-1:
How to see the list of all 5 ciphers of TLSv1.3 shown in manual page?

openssl ciphers -v -ciphersuites 'TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_CCM_SHA256:TLS_AES_128_CCM_8_SHA256' | grep TLSv1.3

Issue-2: If a customer wants to customize the ciphers allowed at openssl (server side), what is the command ? Are the commands different for different TLS Versions.

The ciphers command takes the following form:
openssl ciphers [-help] [-s] [-v] [-V] [-ssl3] [-tls1] [-tls1_1] [-tls1_2] [-tls1_3] [-s] [-psk] [-srp] [-stdname] [-convert name] [-ciphersuites val] [cipherlist]

The cipherlist is the list of TLSv1.2 and below ciphers and the val provided to -ciphersuites is the list of TLSv1.3 ciphers. The -ciphersuites option just takes a list of ciphers, it does not accept things like 'ALL or '!'. So, the only way to get every TLSv1.3 cipher except TLS_CHACHA20_POLY1305_SHA256 is
-ciphersuites 'TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_AES_128_CCM_SHA256:TLS_AES_128_CCM_8_SHA256'

For TLSv1.2, we used to block the weak ciphers because the list of weak ciphers is less.
For TLSv1.3, As the cipher list is less so we have to go with allowed ciphers.
Looks like the mechanism is different for different versions. instead of blocking mode(using !) we have to go with allowed ciphers mode.

@raveendrapadala

Issue-1:
How to see the list of all 5 ciphers of TLSv1.3 shown in manual page?

According to man ciphers it TLSv1.3 you have to  explicitly specify all ciphers by their fullnames: The format for this list is a simple colon (":") separated list of TLSv1.3 ciphersuite names.. So, if i want to get all the information (-V) about supported (-s) it TLSv1.3 (-tls1_3) protocol ciphers, i do like this:
$ openssl ciphers -V -s -tls1_3 -ciphersuites 'TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_CCM_SHA256:TLS_AES_128_CCM_8_SHA256'
          0x13,0x01 - TLS_AES_128_GCM_SHA256  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(128) Mac=AEAD
          0x13,0x02 - TLS_AES_256_GCM_SHA384  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(256) Mac=AEAD
          0x13,0x03 - TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any      Au=any  Enc=CHACHA20/POLY1305(256) Mac=AEAD
          0x13,0x04 - TLS_AES_128_CCM_SHA256  TLSv1.3 Kx=any      Au=any  Enc=AESCCM(128) Mac=AEAD
          0x13,0x05 - TLS_AES_128_CCM_8_SHA256 TLSv1.3 Kx=any      Au=any  Enc=AESCCM8(128) Mac=AEAD


text:
Execution of command missing an option required by usage not reported in output

release: openssl-3.0.5
Hello. The execution of a command missing an option required by usage is not reported in output, as it is elsewhere with "Use -help for summary.". Illustration; missing '-name <argument>'. Command indefinitely processed.
$ openssl ecparam -genkey -noout -out private.ec.key

The manual page of openssl-ecparam says:
       -in filename
           This specifies the input filename to read parameters from or
           standard input if this option is not specified.

Your command is just waiting for domain parameters on standard input.

There is a misunderstanding. The present issue lies in the lack of reaction, for instance from OpenSSL, in regard to task processing a command whose instructions are incomplete. Obviously a generic reaction would be the triggering of an informative message accordingly.

processing a command whose instructions are incomplete

The command is not incomplete. All required parameters are present. The command is doing what you asked it to do, and is waiting for the required input from stdin.
Another question is whether its good design to default to stdin and therefore hang in this way if the required data is not supplied on stdin. Probably not. Better design would be to have a specific parameter requesting input from stdin. But unfortunately that is not possible to change since it would break existing scripts.

All right. Closing accordingly; not planned.

Another question is whether its good design to default to stdin and therefore hang in this way if the required data is not supplied on stdin. Probably not.

Note that this is the exact behaviour of cat(1), so openssl-ecparam is in good company here!

authors: Ricky-Tigg mattcaswell t8m tom-cosgrove-arm


text:
Fix no-sm2 issue

Some code is not covered by the macros.

3 days after approval: done, ready to merge

merged to master as dcea51afe9e3aec83a0c53f435beec9bc0faa07b


text:
Prevent Clang from emitting atomic libcalls

Fixes #16551

Made to work safely for unaligned operands.

We'll need at least an ICLA for this.  These changes are not what I'd consider trivial.

CLA sync

I don't feel comfortable reviewing this, but one non-technical thing we should aim for is to have self contained and meaningful commit messages.
This is a useful resources on the why and how: https://chris.beams.io/posts/git-commit/

The CI failure is relevant - something with the change confuses the make update perl script so it does not recognize the CRYPTO_ATOMIC_add() function in the header anymore.

@levitte any idea about the make update failure?

@t8m @levitte any update on this? I'm still unable to compile 3.0.1 for iOS (#16551)

This PR is in a state where it requires action by @openssl/committers but the last update was 90 days ago

This PR is in a state where it requires action by @openssl/committers but the last update was 121 days ago

Could you please rebase the PR to resolve conflicts?
Marking as inactive to be closed at the end of 3.4 dev barring further input.

authors: ecnepsnai openssl-machine paulidale romen t8m xtkoba


text:
Added documentation for PEM_X509_INFO_read() and PEM_X509_INFO_read_bio()

Fixes: #18342
Checklist

[x] documentation is added or updated

24 hours has passed since 'approval: done' was set, but this PR has failing CI tests.  Once the tests pass it will get moved to 'approval: ready to merge' automatically, alternatively please review and set the label manually.

This goes well beyond what is acceptable under a trivial CLA.  Could you please submit a CLA?

There is also some end of line white space, if you could remove them too.

And furthermore there are merge commits. Not sure, why we did not notice this before. So please rebase your branch on top of fresh master branch and drop the merge commits.

Opened up a new PR
https://github.com/openssl/openssl/pull/18623


text:
Workaround egd rand source deficiencies

With egd as the rand source the reseed after fork confuses the egd.
Fixes #19396
Checklist

[x] tests are added or updated

24 hours has passed since 'approval: done' was set, but this PR has failing CI tests.  Once the tests pass it will get moved to 'approval: ready to merge' automatically, alternatively please review and set the label manually.

Merged to master and 3.0 branches. Thank you for the reviews.


text:
Fail the Configure script with no Configurations

Print a message about why the failure is happening.
Send the usage information.

See this discussion for more information: https://github.com/openssl/openssl/discussions/22826
Checklist

We will need a CLA to accept your contribution. Can you please sign it? https://www.openssl.org/policies/cla.html

24 hours has passed since 'approval: done' was set, but this PR has failing CI tests.  Once the tests pass it will get moved to 'approval: ready to merge' automatically, alternatively please review and set the label manually.

This PR has the label 'hold: cla required' and is stale: it has not been updated in 31 days. Note that this PR may be automatically closed in the future if no CLA is provided.  For CLA help see https://www.openssl.org/policies/cla.html

We will need a CLA to accept your contribution. Can you please sign it? https://www.openssl.org/policies/cla.html

Or could this be considered as trivial?

We will need a CLA to accept your contribution. Can you please sign it? https://www.openssl.org/policies/cla.html

Or could this be considered as trivial?

Unfortunately this is outside of what we can accept with CLA: trivial.

I have signed the CLA, let me see if it executes once I rebase

This pull request is ready to merge

Merged to the master branch. Thank you for your contribution.


text:
Set down_load factor on hash table when culling items in doall

oss-fuzz noted this issue:
https://oss-fuzz.com/testcase-detail/5363002606419968
Which reports a heap buffer overflow during ossl_method_cache_flush_some
Its occuring because we delete items from the hash table while inside its doall iterator
The iterator in lhash.c does a reverse traversal of all buckets in the hash table, and at some point a removal during an iteration leads to the hash table shrinking, by calling contract.  When that happens, the bucket index becomes no longer valid, and if the index we are on is large, it exceeds the length of the list, leading to an out of band reference, and the heap buffer overflow report.
Fix it by preventing contractions from happening during the iteration, but setting the down_load factor to 0, and restoring it to its initial value after the iteration is done

@bernd-edlinger culling was the intended word there:
https://www.dictionary.com/browse/culling

24 hours has passed since 'approval: done' was set, but as this PR has been  updated in that time the label 'approval: ready to merge' is not being automatically set.  Please review the updates and set the label manually.

merged to all active branches, thanks for the review

authors: nhorman openssl-machine


text:
Fix cherry-pick; move file.

Just happened to notice, a cherry-pick gone horribly horribly wrong :)

the 1.0.2 docs subtree is pristine again :)


text:
[WIP] Build rpm packages from zuul opendev depends-on

As a pull request owner and reviewers, I checked that:

[ ] Appropriate testing is done and actually running
[ ] Appropriate documentation exists and/or is up-to-date:

[ ] README in the role
[ ] Content of the docs/source is reflecting the changes

recheck

/hold

/hold cancel

Care to trigger a molecule job for the pkg_build role? It's dependent and we already broke it with changes in bop role :) (also asked on #1457 - I see it's included in this PR, so you can trigger with a depends-on this 1418 one)

/hold
let's wait for https://github.com/openstack-k8s-operators/ci-framework/pull/1457 to merge first if you don't mind.

recheck

authors: cjeanner danpawlik raukadah


text:
Implement sosreport role for log collection

Replace ci_script action with a "sos" log collector. By using industry-provided standard, we ensure that collected logs adhere to standards.
As a pull request owner and reviewers, I checked that:

[x] Appropriate testing is done and actually running
[x] Appropriate documentation exists and/or is up-to-date:

[x] README in the role
[x] Content of the docs/source is reflecting the changes

It is not creating sos.conf file correctly. Needs further investigation.

@dasm sosreport provides an option --config-file to Specify alternate configuration file.  We can use this option and generate sos.conf during roles execution?

authors: dasm raukadah


text:
How to upgrade iD to 2.0.0-beta.1 in OpenStreetMap

just test

Test it at https://openstreetmap.us/iD/master/

yes, please use the link @boothym provided for testing..

authors: bhousel boothym hanchao

repo: openstreetmap/iD

license: ISC


text:
Add scraper for making POST requests

This scraper takes URLs in the database_urls column, then makes a POST request to them, with everything after ?POST_BODY= as the body of the request.  I've included a csv file for easy testing:
bin/edu_repo_crawler.py post_test.csv --local

Currently, it just tests syllabus.kyushu-u.ac.jp but I'll add more as I find them.

I'm going to wait until I try this with some other sites before I merge.

I rebased to remove the test file, remove the depth/hops_from_seed counters (per https://github.com/opensyllabus/osp-scraper/pull/160), and otherwise updated with regards to master.
After testing on a few sites, I can confirm that this feature works, and has the potential to be very useful.  Any other concerns about it, or developing similar solutions for quicker grabbing of sites (e.g., could we use an approach like this for sites that require a single GET form request?), can be addressed in other tickets.

authors: HarrisonGregg jodizzle

repo: opensyllabus/osp-scraper

license_source: bigquery


text:
CLI Ideas

I'm exercising CLI commands. Here are some proposed improvements to the help text.

Current coverage is 58.55% (diff: 0.00%)

Merging #248 into master will not change coverage

@@             master       #248   diff @@
==========================================
  Files           136        136
  Lines          7040       7040
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
  Hits           4122       4122
  Misses         2554       2554
  Partials        364        364

Powered by Codecov. Last update ecaa20c...750967a

Ignoring the coverage fail here, as it doesn't make much sense to require additional coverage for a few textual tweaks.

authors: alrs codecov-io samsalisbury

repo: opentable/sous

license: mit


text:
OTAR015: Integrate Cancer Dependency Map as Evidence

The Cancer Dependency Project Paper has been submitted and after the meeting on June 22nd, 2018, Francesco made the manuscript and data available to us so that we can start defining how the data will fit into the Open Targets Platform.

[x] Read Cancer DepMap paper & become familiar with the data.
[ ] Define inclusion and scoring of the data.
[ ] Specify backend and frontend implementation details.
[ ] Implement in data_pipeline.

Issue moved to opentargets/platform #163 via ZenHub

authors: ElaineMcA MichaelaEBI