//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

[role="_abstract"]
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
Non-EUS versions of {microshift-short} require serial updates. For example, if you attempt to update from {microshift-short} `4.15.5` directly to `4.17.1`, the update fails. You must first update `4.15.5` to `4.16.z`, and then you can update from `4.16.z` to `4.17.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}. Check the following compatibility table:

include::snippets/microshift-rhde-compatibility-table-snip.adoc[leveloffset=+2]

[id="microshift-ostree-update-failed_{context}"]
== {op-system-ostree} update failed
If you updated on an `rpm-ostree` system, the greenboot health check automatically logs and acts on system health. A system rollback by greenboot can indicate an update failure. 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.

* 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, greenboot can indicate an update failure, 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 the `sos report` tool to check both the {microshift-short} update and the host system.