Adding known issue for bare metal firmware updates

Author: abhatt-rh

modules/rn-ocp-release-notes-known-issues.adoc

@@ -30,4 +30,14 @@ For information on the oc-mirror v2 plugin, see _Mirroring images for a disconne
 
 * Currently, pods that use a `guaranteed` QoS class and request whole CPUs might not restart automatically after a node reboot or kubelet restart. The issue might occur in nodes configured with a static CPU Manager policy and using the `full-pcpus-only` specification, and when most or all CPUs on the node are already allocated by such workloads. As a workaround, manually delete and re-create the affected pods. (link:https://issues.redhat.com/browse/OCPBUGS-43280[OCPBUGS-43280])
 
-* On systems using specific AMD EPYC processors, some low-level system interrupts, for example `AMD-Vi`, might contain CPUs in the CPU mask that overlaps with CPU-pinned workloads. This behavior is because of the hardware design. These specific error-reporting interrupts are generally inactive and there is currently no known performance impact.(link:https://issues.redhat.com/browse/OCPBUGS-57787[OCPBUGS-57787])
+* On systems using specific AMD EPYC processors, some low-level system interrupts, for example `AMD-Vi`, might contain CPUs in the CPU mask that overlaps with CPU-pinned workloads. This behavior is because of the hardware design. These specific error-reporting interrupts are generally inactive and there is currently no known performance impact.(link:https://issues.redhat.com/browse/OCPBUGS-57787[OCPBUGS-57787])
+
+* While Day 2 firmware updates and BIOS attribute reconfiguration for bare-metal hosts are generally available with this release, the Bare Metal Operator (BMO) does not provide a native mechanism to cancel a firmware update request once initiated. If a firmware update or setting change for `HostFirmwareComponents` or `HostFirmwareSettings` resources fails, returns an error, or becomes indefinitely stuck, you can try to recover using the following steps:
++
+--
+. Removing the changes to the `HostFirmwareComponents` and `HostFirmwareSettings` resources.
+. Setting the node to `online: false` to trigger a reboot.
+. If the issue persists, deleting the Ironic pod.
+--
++
+A native abort capability for servicing operations might be planned for a future release. (link:https://issues.redhat.com/browse/OCPBUGS-XXXXX[OCPBUGS-XXXXX])