Tengo una instancia Micro que ejecuta Ubuntu 10.04 x86 (AMI ami-3e02f257). Tiene el volumen del sistema operativo adjunto en /dev/sda1 y un segundo volumen adjunto en /dev/sdf (reportado como /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 se parece a:
# /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
Cuando reinicio, /mnt/osm no se conecta. Si ejecuto sudo mount /dev/sdf /mnt/osmel volumen, se conecta inmediatamente. Esto estaba funcionando en una instancia pequeña. Cuando lo eliminé nobootwait, bloqueé la instancia. ¿Alguna sugerencia? El sistema de archivos debe conectarse para que pueda iniciarse el clúster de Postgres que se ejecuta en él.
Respuesta1
¿Has intentado eliminar /dev/sda2? Dado que no está definido en la configuración del dispositivo de bloque que publicó, podría haber un problema ya que el dispositivo no existe. No estoy seguro de si el montaje en el arranque se cancela por error o si intenta montar dispositivos adicionales. Como lo mencionó @ richard-bentley, las instancias respaldadas por EBS no tienen almacenamiento efímero y esta parte del comando fallará.
Es dudoso que el problema tenga algo que ver con el hecho de que se trata de un micro, a menos que haya pasado de una instancia respaldada por S3 a una instancia respaldada por EBS (en relación con el hecho de que el almacenamiento efímero no está predeterminado en las instancias respaldadas por EBS).
Respuesta2
FWIW, tuve el mismo problema en una pequeña instancia de AMI de Amazon Linux y fue causado por la opción nobootwait en la entrada fstab. Se eliminó la opción ofensiva y se montó bien en el arranque.