Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

このコンテンツは選択した言語では利用できません。

Chapter 5. Troubleshooting updates

To troubleshoot MicroShift updates, you can check update paths, review journal and greenboot health check logs, and use other techniques to help you solve update problems.

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). For more information, see "Red Hat Device Edge release compatibility matrix".

5.1.3. RHEL for Edge 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 RHEL for Edge documentation linked in the "Additional resources" section.

  • 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

5.1.4. 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 update and the host system.

5.2. Checking journal logs after updates
リンクのコピー

You can use journal logs to help diagnose MicroShift update failures. The default configuration of the systemd journal service stores data in a volatile directory, which does not persist across restarts. To retain logs across restarts, enable log persistence and set a maximum size limit for journal data.

Procedure

  • Get comprehensive MicroShift journal logs by running the following command: 

    $ sudo journalctl -u microshift

  • Check the greenboot journal logs by running the following command: 

    $ sudo journalctl -u greenboot-healthcheck

  • 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

      Example output

      IDX  BOOT ID                          	FIRST ENTRY                 LAST ENTRY
 0   681ece6f5c3047e183e9d43268c5527f 	<Day> <Date> 12:27:58 UTC 	<Day> <Date>> 13:39:41 UTC
#....

    • Check the journal logs for the specific boot by running the following command: 

      $ sudo journalctl --boot _<idx_or_boot_id>

      where:

      idx_or_boot_id
      Replace <idx_or_boot_id> with the IDX or the BOOT ID number 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>

      where:

      idx_or_boot_id
      Replace <idx_or_boot_id> with the IDX or the BOOT ID number assigned to the specific boot that you want to check.
      service_name
      Replace <service_name> with the name of the service that you want to check.

5.3. Checking the status of greenboot health checks
リンクのコピー

You can check the status of greenboot health checks before making changes to the system or while troubleshooting. By using helpful commands to verify that greenboot scripts have finished running.

Procedure

  • Check the current greenboot health check status by running the following command: 

    $ systemctl show --property=SubState --value greenboot-healthcheck.service

    where:

    start
    Greenboot checks are still running.
    exited
    Checks have passed and greenboot has exited. Greenboot runs the scripts in the green.d directory when the system is in a healthy state.
    failed
    Checks have not passed. Greenboot runs the scripts in the red.d directory when the system is in this state and restarts the system.

  • Check the numerical exit code of the greenboot health check service by running the following command: 

    $ systemctl show --property=ExecMainStatus --value greenboot-healthcheck.service

    An exit code of 0 means the health check succeeded. A non-zero exit code means the health check failed.

  • 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

    Example output

    Boot Status is GREEN - Health Check SUCCESS

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

Legal Notice

Theme

© 2026 Red Hatトップに戻る