** Description changed: Binary package hint: cloud-init - on Amazon's new t1. 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. + 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 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. + 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. + 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 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 ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
