EC2 ボリュームが fstab 経由でマウントされない。手動マウントは成功する。

EC2 ボリュームが fstab 経由でマウントされない。手動マウントは成功する。

Ubuntu 10.04 x86 (AMI ami-3e02f257) を実行している Micro インスタンスがあります。OS ボリュームは /dev/sda1 に接続され、2 番目のボリュームは /dev/sdf に接続されています ( として報告されています/dev/sda1=vol-eaa0e982:attached:2011-03-08T17:17:42.000Z:false, /dev/sdf=vol-44a3ea2c:attached:2011-03-08T17:17:42.000Z:false)。

fstab は次のようになります:

# /etc/fstab: static file system information.
# <file system>               <mount point>   <type>  <options>       <dump>  <pass>
proc                          /proc           proc    nodev,noexec,nosuid 0       0
LABEL=uec-rootfs              /               ext3    defaults        0       0
/dev/sda2  /mnt      auto  defaults,nobootwait,comment=cloudconfig  0  0
/dev/sdf   /mnt/osm  auto  defaults,nobootwait,comment=osmdata      0  0

再起動すると、/mnt/osm がオンラインになりません。実行すると、sudo mount /dev/sdf /mnt/osmボリュームはすぐにオンラインになります。これは Small インスタンスで動作していました。削除すると、nobootwaitインスタンスが壊れてしまいました。何か提案はありますか? ファイルシステムは、その上で実行されている Postgres クラスターを起動できるようにオンラインにする必要があります。

答え1

/dev/sda2 を削除してみましたか? 投稿したブロック デバイス構成では定義されていないため、デバイスが存在しないために問題が発生している可能性があります。起動時のマウントがエラーで中止されるのか、追加のデバイスをマウントしようとするのかはわかりません。@richard-bentley が述べたように、EBS でバックアップされたインスタンスには一時ストレージがないため、コマンドのこの部分は失敗します。

S3 でバックアップされたインスタンスから EBS でバックアップされたインスタンスに変更しない限り、この問題がマイクロであるという事実と何らかの関係があるかどうかは疑わしい (EBS でバックアップされたインスタンスでは一時ストレージがデフォルトで設定されていないという事実に関連)。

答え2

ちなみに、私は小さな Amazon Linux AMI インスタンスで同じ問題を抱えていましたが、これは fstab エントリの nobootwait オプションが原因でした。問題のあるオプションを削除すると、起動時に問題なくマウントされました。

関連情報