cannot establish control of object, already controlled by ProviderRevision on Crossplane v2 upgrade

TL;DR: if upgrading providers under Crossplane v2 fails with cannot establish control of object: [crd] is already controlled by ProviderRevision [old-revision], the CRDs still carry ownerReferences pointing at the old ProviderRevision. Upgrade to the patched v2.0/v2.1 release containing PR #6934. Before the patch, the workaround is to manually delete the old inactive ProviderRevision after upgrading the provider (kubectl delete providerrevision [old-name]), which lets the new revision take control. Multiple reporters confirmed this is much less destructive than deleting the CRDs.

cannot establish control of object: [crd] is already controlled by ProviderRevision [old-revision]

Steps

1. Upgrade Crossplane to the patched v2.0/v2.1 release (PR #6934).

2. Or as a workaround: kubectl delete providerrevision [old-name] after the provider upgrade.

   Expected: the new revision takes control. Success check: providers install cleanly.

When to use this

• Provider upgrades under Crossplane v2 fail with the control error.

When NOT to use this

• Other install errors; read the message.
• Crossplane v1; the revision mechanics differ.

Compatibility

• Crossplane v2 patched releases.

Variant phrasings

• "crossplane cannot establish control of object"
• "crossplane ProviderRevision already controlled"

Root cause

Stale ownerReferences on CRDs block the new revision from adopting them.

Edge cases

• Deleting the CRD outright works but is the nuclear option; prefer deleting the old revision.

Someone asked: Upgrading providers under Crossplane v2, the new ProviderRevision failed to install with cannot establish control of object: [crd] is already controlled by ProviderRevision [old-revision]. The CRDs still carried ownerReferences pointing at the old ProviderRevision, so the new revision could not take control of them. Deleting the CRD outright worked but was the nuclear option. The verified answer: Fixed upstream in PR #6934, which the maintainers released as a v2.0/v2.1 patch; upgrade to the patched release. As a workaround before the patch, manually delete the old inactive ProviderRevision after upgrading the provider (kubectl delete providerrevision [old-name]), which lets the new revision take control of the CRDs. Multiple reporters confirmed this is much less destructive than deleting the CRDs and it resolved the upgrade failure. Full thread: https://vectle.com/threads/thr_7kLOwzsyTVzXWQye7UG6jw