3

I have a Micro instance running Ubuntu 10.04 x86 (AMI ami-3e02f257). It has the OS volume attached at /dev/sda1 and a second volume attached at /dev/sdf (reported as /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 looks like:

# /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

When I reboot, /mnt/osm does not come online. If I run sudo mount /dev/sdf /mnt/osm the volume comes online immediately. This was working on a Small instance. When I removed nobootwait it bricked the instance. Any suggestions? The filesystem needs to come online so that the Postgres cluster running on it can start.

2
  • I added a script to /etc/rc2.d that calls mount -a. Is this micro instance not configured to mount the filesystems on boot by default?
    – Travis P
    Mar 8, 2011 at 18:31
  • Run dmesg and look toward the end of the output for any errors that might be occurring relating to the mounting of the volume at boot.
    – Patches
    Mar 9, 2011 at 0:14

2 Answers 2

3

Have you tried removing /dev/sda2? Since it's not defined in the block device config you posted it could be having an issue since the device doesn't exist. I'm not sure if mount at boot aborts on error or if it tries to mount additional devices. As it was mentioned by @richard-bentley EBS backed instances don't have ephemeral storage and this part of the command will fail.

It's doubtful that the issue has anything to do with the fact that this is a micro unless you went from a S3 backed instance to an EBS backed instance (relating to the fact that ephemeral storage isn't defaulted on EBS backed instances).

1
  • This appears to work. Funny, I had commented out /dev/sda2 a while ago but never tested the system without my /etc/rc2.d/ hack. Thanks for the reply.
    – Travis P
    Apr 25, 2011 at 22:51
2

FWIW, I had this same problem on a small Amazon Linux AMI instance and it was caused by the nobootwait option in the fstab entry. Removed the offending option and it mounted at boot just fine.

2
  • 2
    Proceed with caution. I removed nobootwait on one of the volumes (can't remember which, probably /dev/sda2, the non-existent ephemeral volume) and it bricked the micro instance. Had to re-mount the drive from another running instance and edit fstab to get it in a bootable state again.
    – Travis P
    May 4, 2011 at 15:39
  • 1
    As indicated here you can put the nobootwait as the last one. Fixes the hanging ssh connection.
    – RickyA
    Nov 19, 2012 at 14:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .