| 2010-09-09 14:56:53 |
Scott Moser |
bug |
|
|
added bug |
| 2010-09-09 14:56:53 |
Scott Moser |
attachment added |
|
Dependencies.txt https://bugs.launchpad.net/bugs/634102/+attachment/1560941/+files/Dependencies.txt |
|
| 2010-09-09 15:00:37 |
Scott Moser |
summary |
cloud-init writes ephemeral0 entry in /etc/fstab on t1.micro type |
t1.micro instances hang on reboot |
|
| 2010-09-09 15:05:05 |
Scott Moser |
description |
Binary package hint: cloud-init
on Amazon's new t1.micro instance type, there is no ephemeral storage at all.
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.
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 |
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.
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/sda1,s,^,#,' /etc/fstab
2.) launch instance with cloud-config metadata containing:
#cloud-config
mounts:
- [ ephemeral0 ]
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
|
|
| 2010-09-09 15:06:15 |
Scott Moser |
description |
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.
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/sda1,s,^,#,' /etc/fstab
2.) launch instance with cloud-config metadata containing:
#cloud-config
mounts:
- [ ephemeral0 ]
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
|
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.
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 ]
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
|
|
| 2010-09-09 15:18:19 |
Scott Moser |
nominated for series |
|
Ubuntu Lucid |
|
| 2010-09-09 15:18:19 |
Scott Moser |
bug task added |
|
cloud-init (Ubuntu Lucid) |
|
| 2010-09-09 16:02:11 |
Thierry Carrez |
nominated for series |
|
Ubuntu Maverick |
|
| 2010-09-09 16:02:11 |
Thierry Carrez |
bug task added |
|
cloud-init (Ubuntu Maverick) |
|
| 2010-09-09 16:02:39 |
Thierry Carrez |
cloud-init (Ubuntu Maverick): importance |
Undecided |
Medium |
|
| 2010-09-09 16:02:39 |
Thierry Carrez |
cloud-init (Ubuntu Maverick): status |
New |
Confirmed |
|
| 2010-09-09 16:02:39 |
Thierry Carrez |
cloud-init (Ubuntu Maverick): assignee |
|
Scott Moser (smoser) |
|
| 2010-09-09 17:01:40 |
Eric Hammond |
bug |
|
|
added subscriber Eric Hammond |
| 2010-09-09 17:07:35 |
Marius Seritan |
bug |
|
|
added subscriber Marius Seritan |
| 2010-09-09 17:30:53 |
Scott Moser |
cloud-init (Ubuntu Lucid): importance |
Undecided |
High |
|
| 2010-09-09 17:30:53 |
Scott Moser |
cloud-init (Ubuntu Lucid): status |
New |
Triaged |
|
| 2010-09-09 17:30:53 |
Scott Moser |
cloud-init (Ubuntu Lucid): milestone |
|
lucid-updates |
|
| 2010-09-09 17:32:08 |
Scott Moser |
description |
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.
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 ]
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
|
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
2.) launch instance with cloud-config metadata containing:
#cloud-config
mounts:
- [ ephemeral0 ]
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
|
|
| 2010-09-09 19:43:28 |
Ben Howard |
bug |
|
|
added subscriber Ben Howard |
| 2010-09-09 20:53:10 |
aljosa |
bug |
|
|
added subscriber aljosa |
| 2010-09-09 20:57:03 |
Scott Moser |
description |
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
2.) launch instance with cloud-config metadata containing:
#cloud-config
mounts:
- [ ephemeral0 ]
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
|
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.
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.
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
|
|
| 2010-09-09 21:21:01 |
Scott Moser |
description |
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.
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.
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
|
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
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
|
|
| 2010-09-09 21:28:20 |
Jon |
bug |
|
|
added subscriber Jon |
| 2010-09-10 00:16:39 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/lucid-proposed/cloud-init |
|
| 2010-09-10 00:16:46 |
Launchpad Janitor |
branch linked |
|
lp:cloud-init |
|
| 2010-09-10 09:55:35 |
Thierry Carrez |
tags |
|
server-mrs |
|
| 2010-09-10 15:27:40 |
Thierry Carrez |
cloud-init (Ubuntu Maverick): milestone |
|
ubuntu-10.10 |
|
| 2010-09-10 18:46:35 |
Scott Moser |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2010-09-10 21:57:56 |
Doug Stanley |
bug |
|
|
added subscriber Doug Stanley |
| 2010-09-10 23:47:07 |
Rod |
bug |
|
|
added subscriber Rod |
| 2010-09-11 02:13:15 |
Cristian Gafton |
bug |
|
|
added subscriber Cristian Gafton |
| 2010-09-11 03:55:11 |
Shane O'Connell |
bug |
|
|
added subscriber Shane O'Connell |
| 2010-09-11 15:37:06 |
Nick W. |
bug |
|
|
added subscriber Nick W. |
| 2010-09-12 19:34:25 |
Launchpad Janitor |
branch linked |
|
lp:~cloud-init-dev/cloud-init/maverick |
|
| 2010-09-12 20:13:29 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/cloud-init |
|
| 2010-09-13 12:54:17 |
Scott Moser |
summary |
t1.micro instances hang on reboot |
t1.micro EC2 instances hang on reboot |
|
| 2010-09-13 12:56:03 |
Scott Moser |
description |
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
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
|
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.) 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
|
|
| 2010-09-13 13:36:02 |
brian mullan |
bug |
|
|
added subscriber brian mullan |
| 2010-09-13 16:49:11 |
David Kennedy |
bug |
|
|
added subscriber David Kennedy |
| 2010-09-13 19:27:17 |
Scott Moser |
cloud-init (Ubuntu Maverick): status |
Confirmed |
Fix Released |
|
| 2010-09-14 07:38:41 |
Sander de Bruijne |
bug |
|
|
added subscriber Sander de Bruijne |
| 2010-09-14 13:59:45 |
Stephen Haynes |
bug |
|
|
added subscriber Stephen Haynes |
| 2010-09-16 08:13:25 |
Martin Pitt |
cloud-init (Ubuntu Lucid): status |
Triaged |
Fix Committed |
|
| 2010-09-16 08:13:34 |
Martin Pitt |
bug |
|
|
added subscriber SRU Verification |
| 2010-09-16 08:13:37 |
Martin Pitt |
tags |
server-mrs |
server-mrs verification-needed |
|
| 2010-09-16 13:18:11 |
Scott Moser |
tags |
server-mrs verification-needed |
server-mrs verification-done |
|
| 2010-09-16 17:24:57 |
Jamie Krug |
bug |
|
|
added subscriber Jamie Krug |
| 2010-09-16 20:14:26 |
David Hisel |
bug |
|
|
added subscriber David Hisel |
| 2010-09-16 23:44:58 |
Dana Spiegel |
bug |
|
|
added subscriber Dana Spiegel |
| 2010-09-17 07:34:58 |
Peter Smit |
cloud-init (Ubuntu Lucid): status |
Fix Committed |
Fix Released |
|
| 2010-09-17 07:35:03 |
Peter Smit |
cloud-init (Ubuntu Lucid): status |
Fix Released |
Fix Committed |
|
| 2010-09-17 07:36:08 |
Peter Smit |
bug |
|
|
added subscriber Peter Smit |
| 2010-09-17 20:43:22 |
Launchpad Janitor |
branch linked |
|
lp:~cloud-init-dev/ubuntu/lucid/cloud-init/lucid |
|
| 2010-09-19 03:09:01 |
Owen Farrell |
bug |
|
|
added subscriber Owen Farrell |
| 2010-09-19 16:40:15 |
Mingfai Ma |
bug |
|
|
added subscriber Mingfai Ma |
| 2010-09-22 09:00:54 |
Niels Wind |
bug |
|
|
added subscriber Niels Wind |
| 2010-09-22 12:42:04 |
Scott Moser |
cloud-init (Ubuntu Lucid): assignee |
|
Scott Moser (smoser) |
|
| 2010-09-22 12:54:55 |
Mingfai Ma |
removed subscriber Mingfai Ma |
|
|
|
| 2010-09-23 08:29:23 |
Launchpad Janitor |
cloud-init (Ubuntu Lucid): status |
Fix Committed |
Fix Released |
|
| 2010-09-23 09:15:40 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/lucid-updates/cloud-init |
|
| 2011-08-29 09:26:55 |
Ray |
bug |
|
|
added subscriber Ray |
