コミュニティソリューション

ZimaBoardがレスキューモードで起動する場合:ZimaOSを安全に復旧する方法

A ZimaBoard 1664 stopped booting after shutdown and entered rescue mode, while its apps and data had previously been moved to an 8 TB drive.

結論:レスキューモードになっても、8 TBのデータドライブを失ったわけではありません

シャットダウン後にシステムが起動しなくなりましたが、ユーザーは以前にアプリデータを8 TBドライブへ移動していました。そのため、最も安全な復旧手順は、まず代替のZimaOSシステムスロットを試し、データディスクを保護し、ブートパーティションを復旧できない場合にのみOSを再インストールすることです。

再インストールする前に代替のZimaOSスロットを試す

現在のZimaOSは、システムパーティションを2つ使用します。モニターとキーボードを接続し、矢印キーでGRUBを開いて、代替スロットから起動してください。ZimaOSシステムリカバリーでは、現在のA/B復旧モデルについて説明しています。

RAUCのRAUCスロットモデルでは基盤となる更新モデルを、GNU GRUBブートメニューではブートローダー層について説明しています。

復旧中に8 TBのデータドライブをフォーマットしない

新しいOSのインストールとデータディスクは別のものです。AppDataとメディアを8 TBドライブへ移行していた場合は、まずそのディスクを保護してください。ZimaOSはシステムデバイスにのみ再インストールします。

ZimaOSインストールリカバリーが、フォールバック手順になります。

再インストール後は、既存のアプリデータを意図的に再接続する

すべてのアプリが古い設定を自動的に再検出すると期待しないでください。8 TBドライブをマウントし、以前のAppDataフォルダーを確認してから、同じアプリケーションを再インストールするか、永続化パスを既存のデータに戻します。

ZimaOSデータ移行では、現在のアプリデータの場所と移行動作について説明しています。

「Ethernetが読み込まれなかった」ことが確かな根本原因ではない理由

レスキューモードでは、システム全体が通常のサービスを起動する段階まで到達していないため、通常のネットワーク機能が利用できない場合があります。そのため、レスキューモードでEthernetが使えないことだけでは、NICが起動失敗の原因だったとは証明できません。まず起動を診断し、ネットワークはその後に確認してください。

復旧後は、再構築に手間がかかるものをバックアップする

アプリのデータベース、Composeファイル、メディアインデックス、代替のないユーザーデータを保護してください。システムスロットは復元できますが、何年分ものアプリ状態を再構築することが大きな負担になります。