1
0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-07 00:48:01 +01:00
Files
openshift-docs/modules/microshift-updates-troubleshooting.adoc
2024-09-19 19:07:03 +00:00

54 lines
3.0 KiB
Plaintext

//Module included in the following assemblies:
//
//* microshift_troubleshooting/microshift-updates-troubleshooting.adoc
:_mod-docs-content-type: CONCEPT
[id="microshift-troubleshooting-updates_{context}"]
= Troubleshooting {microshift-short} updates
In some cases, {microshift-short} might fail to update. In these events, it is helpful to understand failure types and how to troubleshoot them.
//[id="microshift-update-path-blocked-by-version-sequence_{context}"]
//== Update path is blocked by {microshift-short} version sequence
//Certain versions of {microshift-short} require serial updates. Attempting to update {microshift-short} by skipping a minor version fails:
//* For example, if your current version is `4.14.5`, but you try to update from that version to `4.16.0`, the message, `executable (4.16.0) is too recent compared to existing data (4.14.5): version difference is 2, maximum allowed difference is 1` appears and {microshift-short} fails to start.
//In this example, you must first update `4.14.5` to a version of `4.15`, and then you can upgrade to `4.16.0`.
[id="microshift-update-path-blocked-by-version-incompatibility_{context}"]
== Update path is blocked by version incompatibility
RPM dependency errors result if a {microshift-short} update is incompatible with the version of {op-system-ostree-first} or {op-system-base-full}.
[id="microshift-compatibility-table_{context}"]
=== Compatibility table
Check the following compatibility table:
include::snippets/microshift-rhde-compatibility-table-snip.adoc[leveloffset=+2]
[id="microshift-version-compatibility_{context}"]
=== Version compatibility
Check the following update paths:
*{product-title} update paths*
* Generally Available Version 4.17.1 to 4.17.z on {op-system-ostree} 9.4
* Generally Available Version 4.15.0 from {op-system-base} 9.2 to 4.16.0 on {op-system-base} 9.4
* Generally Available Version 4.14.0 from {op-system-base} 9.2 to 4.15.0 on {op-system-base} 9.4
[id="microshift-ostree-update-failed_{context}"]
== OSTree update failed
If you updated on an OSTree system, the Greenboot health check automatically logs and acts on system health. A failure can be indicated by a system rollback by Greenboot. In cases where the update failed, but Greenboot did not complete a system rollback, you can troubleshoot using the {op-system-ostree} documentation linked in the "Additional resources" section that follows this content.
Checking the Greenboot logs manually::
* Manually check the Greenboot logs to verify system health by running the following command:
+
[source,terminal]
----
$ sudo systemctl restart --no-block greenboot-healthcheck && sudo journalctl -fu greenboot-healthcheck
----
[id="microshift-rpm-update-failed_{context}"]
== Manual RPM update failed
If you updated by using RPMs on a non-OSTree system, an update failure can be indicated by Greenboot, but the health checks are only informative. Checking the system logs is the next step in troubleshooting a manual RPM update failure. You can use Greenboot and `sos report` to check both the {microshift-short} update and the host system.