OpenShift 4.22 closes a multi-architecture update trap that could strand RHCOS nodes

Red Hat’s OpenShift 4.22 release notes flag an unusually sharp update boundary: a node can become unrecoverable while a 4.21 cluster using the multi-architecture payload moves to some 4.22 builds. The fix is in the Machine Config Operator path that installs Red Hat Enterprise Linux CoreOS updates, not in Open vSwitch itself.

Which clusters are exposed

The affected transition starts with OpenShift 4.21 using a multi-architecture release payload. Red Hat says nodes upgrading from that state to 4.22.15 or later affected builds could fail their in-place operating-system update because an rpm-ostree path dropped Open vSwitch binaries from the derived RHCOS image. Single-architecture payload clusters are not affected by this bug.

The project’s update-graph history narrows the practical danger window. OpenShift’s Cincinnati data marks the MultiArchPayloadMissingOpenVSwitch block as fixed in 4.22.18, while the current Red Hat release notes document the correction under 4.22.19. Operators should therefore treat 4.22.18 as the first fixed target and prefer the current recommended 4.22.z offered by their update channel rather than forcing an older explicit image.

Checks before updating

First, identify the cluster’s current payload architecture:

oc get -o json clusterversion version \
  | jq -c '.status.desired | {version, architecture}'

A result showing a 4.21 version with "architecture":"Multi" is the combination that deserves the guardrail. Then inspect the available update recommendation rather than bypassing the graph:

oc adm upgrade

Before approving the update, operators should also confirm that the cluster is available, no earlier update is still progressing, and all nodes are ready. The upstream verification for the fix checked node readiness and the final ClusterVersion state after moving a 4.21.35 multi-architecture cluster to a fixed 4.22 payload.

What changed, and what recovery means

The Machine Config Operator patch changes its fallback for older hosts. It pulls the target operating-system image inside the target OS container, imports the complete image into the host OSTree repository, and rebases directly to that imported commit. That avoids the earlier path that could discard derived layers containing OVS, CRI-O and kubelet.

The published release note documents a preventive recovery path: move through a fixed payload so the Machine Config Daemon can complete the transition. It does not publish a generic command that reconstructs an already damaged node in place. If an update has already left a node without the required binaries, operators should stop forcing the rollout and use their supported node-replacement or control-plane disaster-recovery procedure with Red Hat Support, depending on the node’s role. The important distinction is that 4.22.18 and later prevent the bad image transition; they are not presented as an automatic repair for a node that can no longer boot.