** Summary changed:
- t1.micro instances hang on reboot
+ t1.micro EC2 instances hang on reboot
** Description changed:
Binary package hint: cloud-init
on Amazon's new t1.micro instance type, there is no ephemeral storage at
all. If you run a ubuntu ebs image on instance type t1.micro and
reboot, it will not come back up. mountall will wait indefinitely for
/dev/sda2, which is never going to be present.
cloud-init is basically hard coded to expect an 'ephemeral0', while
other ephemeral devices are more dynamic.
Our images are registered with block-device-mapping indicating
ephemeral0, so the metadata service will include ephemeral0 even though
there is not one on the instance itself.
We need to do one of 2 things here:
a.) add 'nobootwait' for the ephemeral0 device (/dev/sda2 in this case)
b.) not write a entry in /etc/fstab (or comment it out) if that device is not
present on the first boot.
There are 2 easy workarounds for this:
- 1.) sudo sed -i.dist '\,/dev/sda2,s,^,#,' /etc/fstab
+ 1.) copy and paste the following after first boot and ssh in:
+ [ "$(uname -m)" = "x86_64" ] && ephd=/dev/sdb || ephd=/dev/sda2
+ sudo sed -i.dist "\,${ephd},s,^,#," /etc/fstab
+
2.) launch instance with cloud-config metadata containing:
#cloud-config
mounts:
- [ ephemeral0 ]
### SRU Information BEGIN ####
1. This bug affects anyone who is going to run an ec2 instance of type
t1.micro . It is expected that this will be lots of people, especially those
evaluating EC2 and/or Ubuntu. The bug is that the system will only boot and be
reachable one time. On subsequent boots, the ssh service will not start,
leaving a cloud instance completely unreachable. That is because on first boot
an entry is written to /etc/fstab that will never be present.
2. The bug if fixed by
a.) carefully updating existing entries in /etc/fstab to add 'nobootwait'.
Only ephemeral devices are modified (either /dev/sda2 or /dev/sdb), and only if
they contain 'comment=cloudconfig'.
b.) on future first-boots, writing 'nobootwait' for the entry.
3. The patch is available at lp:~cloud-init-dev/cloud-init/lucid, in changes
seen at
http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/lucid/revision/19?remember=15&compare_revid=15
4. To reproduce:
a.) start ec2 lucid instance of t1.micro
ec2-run-instances --region us-east-1 --key mykey ami-1437dd7d
b.) ssh to instance and reboot
sudo reboot
c.) ssh will not come up, leaving the instance basically dead.
5. The opportunity for regression is almost completely contained in the
pre-install script, and here it is very small. The only real negative fallout
would be adding 'nobootwait' to an entry in /etc/fstab that the user *wanted*
to wait on. This is very unlkely.
######### SRU Information END ##############
ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: cloud-init 0.5.10-0ubuntu1.2
ProcVersionSignature: User Name 2.6.32-308.15-ec2 2.6.32.15+drm33.5
Uname: Linux 2.6.32-308-ec2 i686
Architecture: i386
Date: Thu Sep 9 14:42:21 2010
Ec2AMI: ami-1234de7b
Ec2AMIManifest: (unknown)
Ec2AvailabilityZone: us-east-1c
Ec2InstanceType: t1.micro
Ec2Kernel: aki-5037dd39
Ec2Ramdisk: unavailable
PackageArchitecture: all
ProcEnviron:
PATH=(custom, user)
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: cloud-init
--
t1.micro EC2 instances hang on reboot
https://bugs.launchpad.net/bugs/634102
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
