Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question
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 Pettijohn Mar 8 '11 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 '11 at 0:14
up vote 2 down vote accepted

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).

share|improve this answer
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 Pettijohn Apr 25 '11 at 22:51

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.

share|improve this answer
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 Pettijohn May 4 '11 at 15:39
As indicated here you can put the nobootwait as the last one. Fixes the hanging ssh connection. – RickyA Nov 19 '12 at 14:00

You must log in to answer this question.

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