Linuxベース・インスタンスでの破損したブート・ボリュームのリカバリ
インスタンスが正常に起動できなかった場合、またはブート・ボリューム・セットが読取り専用アクセスに設定された状態で起動した場合、インスタンスのブート・ボリュームが破損している可能性があります。まれですが、ブート・ボリュームの破損は次のシナリオで発生することがあります:
-
インスタンスでAPIを使用した強制シャットダウンが行われた場合。
-
オペレーティング・システム・エラーまたはソフトウェア・エラーが原因でインスタンスがハングアップし、さらにインスタンスの正常な再起動またはシャットダウンがタイムアウトになり、その後で強制シャットダウンが行われた場合。
-
基礎となるインフラストラクチャの障害や停止が発生し、重要なディスク書込みがシステム内で保留になっている場合。
ほとんどのケースでは、再起動するだけでブート・ボリュームの破損の問題は解決されます。したがって、トラブルシューティングで最初に行う必要があるのはこの操作です。
このトピックでは、Linuxベース・インスタンスのブート・ボリュームが破損しているかどうかを判断する方法と、破損したブート・ボリュームのトラブルシューティングおよびリカバリに必要なステップについて説明します。Windowsインスタンスについては、Windowsインスタンスでの破損したブート・ボリュームのリカバリを参照してください。
ブート・ボリューム破損の検出
ブート・ボリュームが破損すると、インスタンスが正常に起動しなくなる可能性があり、SSHを使用してインスタンスに接続できなくなることがあります。かわりに、インスタンス・コンソール接続機能を使用して、障害のあるインスタンスに接続できます。この機能の使用の詳細は、インスタンス・コンソール接続を使用したインスタンスのトラブルシューティングを参照してください。
この項では、シリアル・コンソール接続を使用して、ブート・ボリュームの破損が発生したかどうかを検出する方法について説明します。
インスタンスのブート・ボリュームが破損していることをすでに確認した場合、またはインポートしたカスタム・イメージを使用している場合は、ブート・ボリュームのリカバリの項に進みます。ここでは、もう1つのインスタンスと標準ファイルシステム・ツールで使用して、ブート・ボリュームの破損を検出して修復する方法を説明します。
- インスタンスのシリアル・コンソール接続を作成します。
-
システムはすでにクラッシュしている可能性があるため、この時点でシリアル・コンソールがハングアップしているように見えるのは正常です。
- コンソールからインスタンスを再起動します。
-
再起動プロセスが開始した後で、ターミナル・ウィンドウに切り替えると、ウィンドウでインスタンスからのシステム・メッセージの表示が始まります。
-
システムの起動につれて表示されるメッセージをモニターします。ほとんどのオペレーティング・システムでは、ディスク破損が検出されるとすぐにブート・ボリュームが読み取り専用に設定されます、書込みによってボリュームがさらに破損されないようにするためです。したがって、ブート・ボリュームが読取り専用モードであることを示すメッセージを探してください。次に例を示します:
-
iSCSIでブート・ボリュームがアタッチされたインスタンスでは、ボリュームが読取り専用モードであるため、
iscsiadmサービスがボリュームをアタッチできません。通常、これによってインスタンスは起動を継続できなくなります。シリアル・コンソールに、次のようなメッセージが表示される可能性があります:iscsiadm: Maybe you are not root? iscsiadm: Could not lock discovery DB: /var/lock/iscsi/lock.write: Read-only file system touch: cannot touch `/var/lock/subsys/iscsid': Read-only file system touch: cannot touch `/var/lock/subsys/iscsi': Read-only file system -
準仮想化ブート・ボリュームがアタッチされたインスタンスでは、システムがブート・プロセスを継続できる場合がありますが、状態は低下します。ブート・ドライブに何も書き込めなくなるためです。シリアル・コンソールに、次のようなエラー・メッセージが表示される可能性があります:
[FAILED] Failed to start Create Volatile Files and Directories. See 'systemctl status systemd-tmpfiles-setup.service' for details. ... [ 27.160070] cloud-init[819]: os.chmod(path, real_mode) [ 27.166027] cloud-init[819]: OSError: [Errno 30] Read-only file system: '/var/lib/cloud/data'
ここで説明したエラー・メッセージやシステム動作は、ブート・ボリュームが破損したときによく見られるものですが、オペレーティング・システムによって異なるため、様々なエラー・メッセージとシステム動作が見られる場合があります。ここで説明したものと異なる場合は、トラブルシューティング方法の詳細について、オペレーティング・システムのドキュメントを参照してください。
-
ブート・ボリュームのリカバリ
破損したブート・ボリュームのトラブルシューティングおよびリカバリを行うには、そのブート・ボリュームをインスタンスからデタッチしてから、データ・ボリュームとして2番目のインスタンスにアタッチする必要があります。
ブート・ボリュームのデタッチ
インスタンスのブート・ボリュームが破損したことを検出した場合は、トラブルシューティングとリカバリのステップを開始する前に、そのインスタンスからブート・ボリュームをデタッチする必要があります。
2番目のインスタンスのデータ・ボリュームとしてのブート・ボリュームのアタッチ
2番目のインスタンスとして、ブート・ボリュームのインスタンスのオペレーティング・システムに最も近いオペレーティング・システムを実行するインスタンスを使用することをお薦めします。Linuxベース・インスタンスのブート・ボリュームは、他のLinuxベース・インスタンスのみにアタッチする必要があります。2番目のインスタンスは、ブート・ボリュームのインスタンスと同じ可用性ドメインおよびリージョン内に存在する必要があります。使用可能な既存インスタンスがない場合は、インスタンスの作成に示すステップを使用して新しいLinuxインスタンスを作成します。2番目のインスタンスが用意できたら、リカバリ・ステップを続行する前に、インスタンスにログインすることができ、インスタンスが機能していることを確認します。インスタンスにアクセスするステップは、Linuxインスタンスへの接続を参照してください。インスタンスが機能していることを確認したら、次のステップを行います。
-
lsblkコマンドを実行し、次の例のように現在インスタンス上にあるドライブをノートにとります:lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 46.6G 0 disk ├─sda2 8:2 0 8G 0 part [SWAP] ├─sda3 8:3 0 38.4G 0 part / └─sda1 8:1 0 200M 0 part /boot/efi - ブート・ボリュームを2番目のインスタンスにデータ・ボリュームとしてアタッチします。詳細は、インスタンスへのブロック・ボリュームのアタッチを参照してください。ブート・ボリュームをデータ・ボリュームとしてアタッチするには
- ナビゲーション・メニューを開き、「コンピュート」をクリックします。「コンピュート」で、「インスタンス」をクリックします。
- ボリュームをアタッチするインスタンスをクリックします。
- 「リソース」で、「アタッチされたブロック・ボリューム」をクリックします。
- 「ブロック・ボリュームのアタッチ」をクリックします。
-
ボリューム・アタッチメント・タイプを選択します。このインスタンスで「準仮想化」アタッチメントが使用可能な場合は、この手順でこのアタッチメント・タイプを選択することをお薦めします。
ボリューム・アタッチメント・タイプとして「iSCSI」を選択する場合は、ボリュームに接続する必要があります。詳細は、ブロック・ボリュームへの接続を参照してください。
- 「ブロック・ボリューム・コンパートメント」ドロップダウン・リストで、コンパートメントを選択します。
- 「ボリュームの選択」オプションを選択し、「ブロック・ボリューム」ドロップダウン・リストの「ブート・ボリューム」セクションでボリュームを選択します。
- アクセス・タイプとして「読取り/書込み」を選択します。
-
「アタッチ」をクリックします。
ボリュームのアイコンが「アタッチ中」として表示されなくなったら、次のステップに進みます。
lsblkコマンドを再度実行して、ブート・ボリュームがインスタンスにアタッチされたボリュームとして表示されていることを確認します。lsblkのこのサンプル出力では、データ・ボリュームとしてアタッチされたブート・ボリュームはsdbとして表示されます:lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb 8:16 0 46.6G 0 disk ├─sdb2 8:18 0 8G 0 part ├─sdb3 8:19 0 38.4G 0 part └─sdb1 8:17 0 200M 0 part sda 8:0 0 46.6G 0 disk ├─sda2 8:2 0 8G 0 part [SWAP] ├─sda3 8:3 0 38.4G 0 part / └─sda1 8:1 0 200M 0 part /boot/efi-
ボリュームのルート・パーティションで
fsckコマンドを実行します。通常、ルート・パーティションはボリューム上の最大のパーティションです。fsckコマンドの次のサンプルは、Oracle 7.6インスタンスについてパーティションにエラーや破損がない場合の出力を示しています。sudo fsck -V /dev/sdb1 fsck from util-linux 2.23.2 [/sbin/fsck.vfat (1) -- /boot/efi] fsck.vfat /dev/sdb1 fsck.fat 3.0.20 (12 Jun 2013) /dev/sdb1: 17 files, 2466/51145 clusters sudo fsck -V /dev/sdb2 fsck from util-linux 2.23.2 sudo fsck -V /dev/sdb3 fsck from util-linux 2.23.2 [/sbin/fsck.xfs (1) -- /] fsck.xfs /dev/sdb3 If you wish to check the consistency of an XFS filesystem or repair a damaged filesystem, see xfs_repair(8).パーティションにエラーがある場合は、通常、エラーの修復を求めるプロンプトが表示されます。次に示すのは、Ubuntuインスタンスの破損したext4ブート・ボリュームの対話型修復セッションの例です:
sudo fsck -V /dev/sdb1 fsck from util-linux 2.31.1 [/sbin/fsck.ext4 (1) -- /] fsck.ext4 /dev/sdb1 e2fsck 1.44.1 (24-Mar-2018) One or more block group descriptor checksums are invalid. Fix<y> yes Group descriptor 92 checksum is 0xe9a1, should be 0x1f53. FIXED. Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information Block bitmap differences: Group 92 block bitmap does not match checksum. FIXED. cloudimg-rootfs: ***** FILE SYSTEM WAS MODIFIED ***** cloudimg-rootfs: 75336/5999616 files (0.1% non-contiguous), 798678/12181243 blocksノート
通常、XFSファイルシステムは、システムがブートするときに内容の自動修復を行うため、破損はブート・プロセス中に修正されます。ブート・ボリュームの破損のために自動修復機能が動作しないシナリオでは、次の例に示すように、
xfs_repairコマンドを使用して修復を強制的に行うことができます:sudo xfs_repair /dev/sdb3 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... ... Phase 7 - verify and correct link counts... done