Oracle Cloud Infrastructureドキュメント

従来のfstabオプション

Linuxインスタンスのブート時にボリュームを自動的にマウントする場合は、/etc/fstabファイルに特定のオプションを設定する必要があるか、またはインスタンスの起動が失敗する可能性があります。

ノート

次のステップは、「一貫性のあるデバイス・パス」が有効になっていないブロック・ボリュームが対象です。
ブロック・ボリュームで整合性のあるデバイス・パスが有効になっている場合は、「/etc/fstab一貫性のあるデバイス・パスを使用したブロック・ボリュームのオプション」を使用します。

ボリュームUUID

Linuxオペレーティング・システムでは、ボリュームがアタッチされる順序は決定的ではないため、再起動するたびに変更される可能性があります。 /dev/sdbなどのデバイス名を使用してボリュームを参照し、複数のルート以外のボリュームがある場合、特定のデバイス名にマウントするボリュームがマウントされたボリュームであるとは保証できません。

この問題を回避するには、デバイス名の代わりに/etc/fstabファイルにボリュームUUIDを指定します。 UUIDを使用すると、マウント・プロセスはスーパー・ブロックのUUIDと/etc/fstabファイルで指定されたマウント・ポイントを一致させます。 このプロセスは、同じボリュームが常に同じマウント・ポイントにマウントされることを保証します。

ボリュームのUUIDの決定

  1. 「ボリュームのアタッチ」および「ボリュームへの接続」のステップに従います。

  2. ボリュームが接続されたら、標準のLinuxツールを使用して、各ボリュームの選択したファイルシステムを作成します。

    残りのステップでは、3つのボリュームが接続されており、各ボリュームにXFSファイル・システムが作成されていることを前提としています。

  3. 次のコマンドを実行して、blkidユーティリティを使用してボリュームのUUIDを取得します:

    sudo blkid

    出力は次のようになります:

    {{ /dev/sda3: UUID="1701c7e0-7527-4338-ae9f-672fd8d24ec7" TYPE="xfs" PARTUUID="82d2ba4e-4d6e-4a33-9c4d-ba52db57ea61"}}
    {{ /dev/sda1: UUID="5750-10A1" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="082c26fd-85f5-4db2-9f4e-9288a3f3e784"}}
    {{ /dev/sda2: UUID="1aad7aca-689d-4f4f-aff0-e0d46fc1b89f" TYPE="swap" PARTUUID="94ee5675-a805-49b2-aaf5-2fa15aade8d5"}}
    {{ /dev/sdb: UUID="699a776a-3d8d-4c88-8f46-209101f318b6" TYPE="xfs"}}
    {{ /dev/sdd: UUID="85566369-7148-4ffc-bf97-50954cae7854" TYPE="xfs"}}
    {{ /dev/sdc: UUID="ba0ac1d3-58cf-4ff0-bd28-f2df532f7de9" TYPE="xfs"}}

    この出力のルート・ボリュームは/dev/sda*です。 追加のリモート・ボリュームは次のとおりです:

    • /dev/sdb
    • /dev/sdc
    • /dev/sdd
  4. /mnt/vol1/mnt/vol2、および/mnt/vol3にそれぞれボリュームを自動的にアタッチするには、次のコマンドを使用して3つのディレクトリを作成します:

    bash-4.2$ sudo mkdir /mnt/vol1
    {{ bash-4.2$ sudo mkdir /mnt/vol2}}
    {{ bash-4.2$ sudo mkdir /mnt/vol3}}

_netdevおよびnofailオプションを使用

デフォルトでは、イニシエータの起動前に/etc/fstabファイルが処理されます。 ボリュームがマウントされる前に開始するようにマウント・プロセスを構成するには、/etc/fstabファイルの各行に_netdevオプションを指定します。

ルート・ボリュームを除くボリュームが/etc/fstabファイルにリストされているインスタンスのカスタム・イメージを作成すると、インスタンスがカスタム・イメージから起動できなくなります。 この問題を回避するには、/etc/fstabファイルでnofailオプションを指定します。

3つのボリュームを使用するシナリオ例では、_netdevおよびnofailオプションを持つボリュームの/etc/fstabファイルのエントリは次のとおりです:


UUID=699a776a-3d8d-4c88-8f46-209101f318b6 /mnt/vol1 xfs defaults,_netdev,nofail 0 2
UUID=ba0ac1d3-58cf-4ff0-bd28-f2df532f7de9 /mnt/vol2 xfs defaults,_netdev,nofail 0 2
UUID=85566369-7148-4ffc-bf97-50954cae7854 /mnt/vol3 xfs defaults,_netdev,nofail 0 2

/etc/fstabファイルを更新したら、次のコマンドを使用してボリュームをマウントします:

bash-4.2$ sudo mount -a

インスタンスを再起動して、次のコマンドでリブート時にボリュームが正しくマウントされていることを確認してください:

bash-4.2$ sudo reboot

/etc/fstabファイルに関する問題のトラブルシューティング

/etc/fstabファイルの更新後にインスタンスがリブートに失敗した場合は、/etc/fstabファイルの変更を元に戻す必要があります。 ファイルを更新するには、最初に「インスタンスのシリアル・コンソールに接続」を実行します。 シリアル・コンソール接続を使用してインスタンスにアクセスした場合は、/etc/fstabファイルに対して行った変更の削除、コメント・アウトまたは修正ができます。