У меня есть экземпляр Micro, работающий под управлением Ubuntu 10.04 x86 (AMI ami-3e02f257). Том ОС подключен к /dev/sda1, а второй том подключен к /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
FWIW, у меня была такая же проблема на небольшом экземпляре Amazon Linux AMI, и она была вызвана опцией nobootwait в записи fstab. Удалил проблемную опцию, и она нормально монтировалась при загрузке.