web-dev-qa-db-ja.com

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を実行すると、ボリュームはすぐにオンラインになります。これは小さなインスタンスで機能していました。 nobootwaitを削除すると、インスタンスがブリックされました。助言がありますか？ファイルシステムで実行されているPostgresクラスターを起動できるように、ファイルシステムをオンラインにする必要があります。

mountfstabamazon-ec2
2
Travis Pettijohn

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

この問題が、S3バッキングインスタンスからEBSバッキングインスタンスに移行しない限り、これがマイクロであるという事実と関係があるかどうかは疑わしいです（エフェメラルストレージがEBSバッキングインスタンスでデフォルト設定されていないという事実に関連しています）。

2
Brad

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

2
Brian