Oracle Cloud Infrastructureドキュメント

Linuxベースのインスタンスの破損したブート・ボリュームのリカバリ

ブート・ボリュームを読取り専用アクセスに設定してインスタンスのブートに失敗した場合、インスタンス・ブート・ボリュームが破損している可能性があります。 まれですが、次のシナリオでは、ブート・ボリュームの破損が発生することがあります:

  • インスタンスでAPIを使用して強制停止が行われる場合。

  • オペレーティング・システムまたはソフトウェア・エラーのためにインスタンスがハングしたり、インスタンスの正常な再起動または停止がタイムアウトしたためにシステムがハングすると、強制停止が発生します。

  • 基礎となるインフラストラクチャでエラーまたは停止が発生し、システムでクリティカル・ディスク書込みが保留中だった場合。

重要

ほとんどの場合、単純な再起動でブート・ボリュームの破損に関する問題が解決されるため、この方法は、このトラブルシューティング時に最初に実行する必要があります。

このトピックでは、Linuxベースのインスタンス・ブート・ボリュームが破損しているかどうか、および破損したブート・ボリュームをトラブルシューティングおよびリカバリするために実行するステップについて説明します。 Windowsインスタンスの場合は、「Windowsインスタンスの破損したブート・ボリュームのリカバリ」を参照してください。

ブート・ボリューム破損の検出

ブート・ボリュームの破損は、インスタンスが正常にブートされないことがあるため、SSHを使用してインスタンスに接続できない可能性があります。 かわりに、インスタンス・コンソール接続機能を使用して、障害の発生しているインスタンスに接続できます。 この機能の使用の詳細は、「インスタンス・コンソール接続」を参照してください。

このセクションでは、シリアル・コンソール接続を使用して、ブート・ボリュームの破損が発生したかどうかを検出する方法について説明します。

ヒント

インスタンスのブート・ボリュームが破損していることをすでに確認しているか、インポートしたカスタム・イメージを使用している場合は、「ブート・ボリュームのリカバリ」のセクションに進みます。このセクションでは、標準のファイル・システム・ツールとともに第2インスタンスを使用して、ブート・ボリュームの破損を検出および修復する方法について説明します。

  1. インスタンスのシリアル・コンソール接続を作成します。

    インスタンスのシリアル・コンソール接続を作成するには
  2. シリアル・コンソールからインスタンスに接続します。

    Mac OS XまたはLinuxでOpenSSHを使用しているインスタンスのシリアル・コンソールに接続するには

    この時点では、システムがクラッシュした可能性があるため、シリアル・コンソールがハングアップしたように見えるのは正常なことです。

  3. コンソールからインスタンスを再起動し、「インスタンスの詳細」ページ「再起動」をクリックします。

  4. 再起動プロセスが開始されたら、端末ウィンドウに戻ります。インスタンスの起動からウィンドウにシステム・メッセージが表示されます。

  5. システムの起動時に表示されるメッセージをモニターします。 ほとんどのオペレーティング・システムでは、ディスク破損が検出されると、ボリュームの破損がさらなることを防ぐために、ブート・ボリュームが読取り専用に設定されます。そのため、ブート・ボリュームを示すメッセージが読取り専用モードであることを示すようになります。 たとえば、次のように指定します。

    • 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番目のインスタンスにデータ・ボリュームとしてアタッチする必要があります。

ブート・ボリュームのデタッチ

インスタンスのブート・ボリュームが破損していることが検出された場合、トラブルシューティングおよびリカバリ・ステップを開始する前に、インスタンスからブート・ボリュームをデタッチする必要があります。

  1. インスタンスを停止します。 詳細は、「インスタンスの停止および起動」を参照してください。

    インスタンスの停止
  2. インスタンスからブート・ボリュームをデタッチします。 詳細は、「ブート・ボリュームのデタッチ」を参照してください。

    インスタンスからブート・ボリュームをデタッチするには

第2インスタンスへのデータ・ボリュームとしてのブート・ボリュームのアタッチ

2番目のインスタンスでは、オペレーティング・システムを実行しているインスタンスを、ブート・ボリューム・インスタンスのオペレーティング・システムに最も近いインスタンスに使用することをお薦めします。 Linuxベースのインスタンスのブート・ボリュームは、他のLinuxベースのインスタンスにのみアタッチする必要があります。 2番目のインスタンスは、ブート・ボリューム・インスタンスと同じ「可用性ドメイン」およびリージョンに存在する必要があります。 既存のインスタンスを使用できない場合は、「インスタンスの作成」で説明されているステップを使用して、新しいLinuxインスタンスを作成します。 2番目のインスタンスが終了したら、必ずインスタンスにログインし、リカバリ・ステップに進む前にそのインスタンスが機能していることを確認してください。 インスタンスへのアクセス・ステップは、「Linuxインスタンスへの接続」を参照してください。 インスタンスが機能していることを確認したら、次のステップを実行します。

  1. 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. データ・ボリュームとして、2番目のインスタンスにブート・ボリュームをアタッチします。 詳細は、「ボリュームをアタッチ」を参照してください。

    ブート・ボリュームをデータ・ボリュームとしてアタッチする場合
  3. 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
  4. ボリューム・ルート・パーティションで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