Red Hat Summit이 콘텐츠는 선택한 언어로 제공되지 않습니다.
Chapter 5. Troubleshoot updates
To troubleshoot MicroShift updates, use the following guide.
5.1. Troubleshooting MicroShift updates
In some cases, MicroShift might fail to update. In these events, it is helpful to understand failure types and how to troubleshoot them.
5.1.1. Update path is blocked by MicroShift version sequence
Non-EUS versions of MicroShift require serial updates. For example, if you attempt to update from MicroShift 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.
5.1.2. Update path is blocked by version incompatibility
RPM dependency errors result if a MicroShift update is incompatible with the version of Red Hat Enterprise Linux for Edge (RHEL for Edge) or Red Hat Enterprise Linux (RHEL).
5.1.2.1. Compatibility table
Check the following compatibility table:
Red Hat Device Edge release compatibility matrix
Red Hat Enterprise Linux (RHEL) and MicroShift work together as a single solution for device-edge computing. You can update each component separately, but the product versions must be compatible. For example, an update of MicroShift from 4.14 to 4.16 or an update from 4.18 to 4.19 requires a Red Hat Enterprise Linux (RHEL) update. Supported configurations of Red Hat Device Edge use verified releases for each together as listed in the following table:
| RHEL Version(s) | MicroShift Version | Supported MicroShift Version → Version Updates |
|---|---|---|
| 9.6 | 4.19 | 4.19.0 → 4.19.z |
| 9.4 | 4.18 | 4.18.0 → 4.18.z, 4.18 → 4.19 on RHEL 9.6 |
| 9.4 | 4.17 | 4.17.1 → 4.17.z, 4.17 → 4.18 |
| 9.4 | 4.16 | 4.16.0 → 4.16.z, 4.16 → 4.17, 4.16 → 4.18 |
| 9.2, 9.3 | 4.15 | 4.15.0 → 4.15.z, 4.15 → 4.16 on RHEL 9.4 |
| 9.2, 9.3 | 4.14 | 4.14.0 → 4.14.z, 4.14 → 4.15, 4.14 → 4.16 on RHEL 9.4 |
5.1.3. 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 RHEL for Edge 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:
sudo systemctl restart --no-block greenboot-healthcheck && sudo journalctl -fu greenboot-healthcheck
$ sudo systemctl restart --no-block greenboot-healthcheck && sudo journalctl -fu greenboot-healthcheckCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.1.4. 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 update and the host system.
5.2. Checking journal logs after updates
In some cases, MicroShift might fail to update. In these events, it is helpful to understand failure types and how to troubleshoot them. The journal logs can assist in diagnosing update failures.
The default configuration of the systemd journal service stores data in a volatile directory. To persist system logs across system starts and restarts, enable log persistence and set limits on the maximum journal data size.
Procedure
Get comprehensive MicroShift journal logs by running the following command:
sudo journalctl -u microshift
$ sudo journalctl -u microshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow Check the greenboot journal logs by running the following command:
sudo journalctl -u greenboot-healthcheck
$ sudo journalctl -u greenboot-healthcheckCopy to Clipboard Copied! Toggle word wrap Toggle overflow Examining the comprehensive logs of a specific boot uses three steps. First list the boots, then select the one you want from the list you obtained:
List the boots present in the journal logs by running the following command:
sudo journalctl --list-boots
$ sudo journalctl --list-bootsCopy to Clipboard Copied! Toggle word wrap Toggle overflow Example output
IDX BOOT ID FIRST ENTRY LAST ENTRY 0 681ece6f5c3047e183e9d43268c5527f <Day> <Date> 12:27:58 UTC <Day> <Date>> 13:39:41 UTC #....
IDX BOOT ID FIRST ENTRY LAST ENTRY 0 681ece6f5c3047e183e9d43268c5527f <Day> <Date> 12:27:58 UTC <Day> <Date>> 13:39:41 UTC #....Copy to Clipboard Copied! Toggle word wrap Toggle overflow Check the journal logs for the specific boot you want by running the following command:
sudo journalctl --boot <idx_or_boot_id>
$ sudo journalctl --boot <idx_or_boot_id>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Replace
<idx_or_boot_id>with theIDXor theBOOT IDnumber assigned to the specific boot that you want to check.
Check the journal logs for the boot of a specific service by running the following command:
sudo journalctl --boot <idx_or_boot_id> -u <service_name>
$ sudo journalctl --boot <idx_or_boot_id> -u <service_name>1 2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3. Checking the status of greenboot health checks
Check the status of greenboot health checks before making changes to the system or during troubleshooting. You can use any of the following commands to help you ensure that greenboot scripts have finished running.
Procedure
To see a report of health check status, use the following command:
systemctl show --property=SubState --value greenboot-healthcheck.service
$ systemctl show --property=SubState --value greenboot-healthcheck.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
An output of
startmeans that greenboot checks are still running. -
An output of
exitedmeans that checks have passed and greenboot has exited. Greenboot runs the scripts in thegreen.ddirectory when the system is a healthy state. -
An output of
failedmeans that checks have not passed. Greenboot runs the scripts inred.ddirectory when the system is in this state and might restart the system.
-
An output of
To see a report showing the numerical exit code of the service where
0means success and non-zero values mean a failure occurred, use the following command:systemctl show --property=ExecMainStatus --value greenboot-healthcheck.service
$ systemctl show --property=ExecMainStatus --value greenboot-healthcheck.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow To see a report showing a message about boot status, such as
Boot Status is GREEN - Health Check SUCCESS, use the following command:cat /run/motd.d/boot-status
$ cat /run/motd.d/boot-statusCopy to Clipboard Copied! Toggle word wrap Toggle overflow
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}