AMIs available in region US-WEST-1?

22 views
Skip to first unread message

Chris Ey

unread,
Dec 3, 2009, 5:01:00 AM12/3/09
to ec2ubuntu
Hi there

first of all "Hi" to everybody, I'm new to this forum and new to AWS in
general (yeah, yet another newbie).

I would like to set up EC2 instances with Ubuntu images in region
"US-WEST-1" but when I view all available AMIs for this region with
ubuntu as a platform I see none. I am able to play with instances in
"US-EAST-1" though.

Does this mean the Ubuntu AMIs have simply not been uploaded to region
US-WEST-1 yet?

Ah yeah, and I will be asking some questions about setting up a MySQL
server with Ubuntu and EBS some time soon too; just in case you already
can recommend a good image to start with. I thought maybe Ubuntu 9.04
Jaunty might make sense as Eric Hammond created a nice tutorial for this
setup already:
http://developer.amazonwebservices.com/connect/entry.jspa?externalID=1663

Thanks a lot
Chris

Scott Moser

unread,
Dec 3, 2009, 5:27:02 PM12/3/09
to ec2ubuntu
On Thu, 3 Dec 2009, Chris Ey wrote:

> Hi there
>
> I would like to set up EC2 instances with Ubuntu images in region
> "US-WEST-1" but when I view all available AMIs for this region with
> ubuntu as a platform I see none. I am able to play with instances in
> "US-EAST-1" though.

They're just not there yet. I had tried to be smart and anticipate
additional regions (by creating buckets) but that appears to have bitten
me [1].

That said, we're working on it. I think the alestic images have faired
better.

--
[1] http://developer.amazonwebservices.com/connect/thread.jspa?messageID=155805&#155805

Eric Hammond

unread,
Dec 4, 2009, 5:03:18 AM12/4/09
to ec2ubuntu
Chris:

The Ubuntu and Debian AMIs I publish were migrated to the us-west-1
region this morning. In fact, your question alerted me to the fact
that it had launched publicly, so thanks :)

I have not yet added AMI ids to http://alestic.com but you can find
the AMIs using normal AMI listing tools like:

ec2-describe-images --all --region us-west-1 |
egrep 063491364108

I published both the 20090804 and 20091011 releases so that folks can
decide which Amazon kernel flaws they want: root escalation security
hole, or lack of support for XFS and fuse (respectively).

I do not recommend starting with Jaunty at this stage (though if you
were already using it, it's fine). If you were willing to use Jaunty,
then I recommend starting instead with the official Karmic AMIs in us-
east-1 for now and migrating over to us-west-1 after Scott gets the
bucket situation sorted out there.

--
Eric Hammond
> setup already:http://developer.amazonwebservices.com/connect/entry.jspa?externalID=...
>
> Thanks a lot
> Chris

David Park

unread,
Dec 4, 2009, 5:16:05 AM12/4/09
to ec2ubuntu
hi eric,

thanks for the great amis.  can you please let me know if your 20091011 64-bit jaunty release has the same problem with xfs?  i created an instance today and it seemed to work fine with xfs - i was able to both reboot and unmount the xfs volume.  fyi, the xfs volume was on a raid array that i created with mdadm first.

david

>
> Thanks a lot
> Chris

--
You received this message because you are subscribed to the "ec2ubuntu" Google Group:
 http://groups.google.com/group/ec2ubuntu
To unsubscribe, send email to ec2ubuntu-...@googlegroups.com

Eric Hammond

unread,
Dec 4, 2009, 6:34:18 AM12/4/09
to ec2u...@googlegroups.com
David:

I don't use Jaunty and haven't tested XFS on Amazon's newest 64-bit kernels.

I strongly recommend you work with the official Ubuntu AMIs from
Canonical (Karmic or Hardy). This is what I plan to do.

--
Eric Hammond
> On Dec 3, 2:01 am, Chris Ey <e...@inweb.de <mailto:e...@inweb.de>>
> <mailto:ec2ubuntu-...@googlegroups.com>

David Park

unread,
Dec 4, 2009, 6:38:41 AM12/4/09
to ec2ubuntu
hi eric,

thanks for the guidance.  i tried to use canonical's official karmic ami before.  but i ran into some problems that were really frustrating - i didn't encounter these problems with your amis.  but this could be due to the fact that i was a total newbie.  i've learned a lot very recently.  and so might not have the same problems that i encountered before.

dp

Scott Moser

unread,
Dec 4, 2009, 11:12:52 AM12/4/09
to ec2ubuntu
On Fri, 4 Dec 2009, David Park wrote:

> hi eric,
>
> thanks for the guidance. i tried to use canonical's official karmic ami
> before. but i ran into some problems that were really frustrating - i
> didn't encounter these problems with your amis. but this could be due to
> the fact that i was a total newbie. i've learned a lot very recently. and
> so might not have the same problems that i encountered before.

I'm interested in hearing what was frustrating.
The goal is *not* to make things that are frustrating :)

Scott Moser

unread,
Dec 7, 2009, 2:20:16 AM12/7/09
to ec2ubuntu
On Thu, 3 Dec 2009, Scott Moser wrote:

> On Thu, 3 Dec 2009, Chris Ey wrote:
>
> > Hi there
> >
> > I would like to set up EC2 instances with Ubuntu images in region
> > "US-WEST-1" but when I view all available AMIs for this region with
> > ubuntu as a platform I see none. I am able to play with instances in
> > "US-EAST-1" though.
>
> They're just not there yet. I had tried to be smart and anticipate
> additional regions (by creating buckets) but that appears to have bitten
> me [1].

Finally. Sorry this took so long, but below is what you're looking for.

ami-173c6d52 ubuntu-images-us-west-1/ubuntu-hardy-8.04-amd64-server-20091130.manifest.xml
ami-153c6d50 ubuntu-images-us-west-1/ubuntu-hardy-8.04-i386-server-20091130.manifest.xml
ami-7b3c6d3e ubuntu-images-us-west-1/ubuntu-karmic-9.10-amd64-server-20091027.1.manifest.xml
ami-7d3c6d38 ubuntu-images-us-west-1/ubuntu-karmic-9.10-i386-server-20091027.1.manifest.xml

Future builds should just pop up on us-west-1 in buckets and images named
according to [1], where the region suffix is 'us-west-1'. For 'us-east-1' and
'eu-west-1' regions, bucket names will continue to have "-us" and "-eu" suffix.
--
[1] https://wiki.ubuntu.com/UEC/Images/NamingConvention

David Park

unread,
Dec 7, 2009, 3:10:48 AM12/7/09
to ec2ubuntu
hi scott,

thanks for the email.  thanks also for all the great work!  the last couple of weeks have been a bit frustrating for me.  but i attribute that mostly to the fact that i'm a newbie and am trying to learn lots of new stuff very quickly.  i feel fortunate that people like you and eric are making these images available to folx like me!

here are the 2 main things that were frustrating for me with the official karmic ami.  i figured out how to get around them.  and i'm now actually using the official canonical karmic amis - 32-bit and 64-bit - because of eric's recommendation.

1. no ec2-ami tools.  i've used ec2 a couple times in the past.  whenever i used it, i always used the ec2-ami tools to create amis from a live instance.  after starting the official canonical ami, i realized that it didn't have the ec2-ami tools.  additionally, i couldn't install the ec2-ami tools by typing apt-get install ec2-ami.  i did some research and realized that i needed to add the multiverse to the list of apt sources.  once i did that, i was able to install the ec2-ami tools.  but it took a while to figure this one out.

2. unstable mounted ebs volumes.  for a couple days, i couldn't get my instances to consistently mount ebs volumes.  after buying premium aws support and talking to a support rep on the phone, i realized that there were 2 reasons for this. 

first, the way in which the ec2-ami tools treats the /etc/fstab file changed since the last time i used ec2 (about a year ago).  back then, the ec2-ami tools wouldn't save the /etc/fstab file on the machine image.  and so i had to create a copy of the /etc/fstab file and then create an init script that would overwrite the default /etc/fstab file with the copy and then mount the volumes.  it is no longer necessary to do this because the current ec2-ami tools save the /etc/fstab file with the image.  the fact that my original images had this init script (which would overwrite /etc/fstab and try to remount the volumes) may have caused some problems.

second, the ec2-bundle-vol tool doesn't include the mount points for mounted directories in the image unless the directory is first unmounted.  for example, i mounted /vol/etc/mysql, which is on the ebs volume, via the mount point /etc/mysql.  if i don't unmount /etc/mysql first, then ec2-bundle-vol won't include the empty directory /etc/mysql in the image.  and so when i create a new instance of this image, it won't be able to mount /vol/etc/mysql because the mount point won't exist.

please let me know if you'd like any more info.   thanks again!

dp




--

Scott Moser

unread,
Dec 7, 2009, 9:38:04 AM12/7/09
to ec2ubuntu
On Mon, 7 Dec 2009, David Park wrote:

> 1. no ec2-ami tools. i've used ec2 a couple times in the past. whenever i

Theres really not a lot we can do about this. The software in the images
is all in "main", meaning it receives full ubuntu support. We are not
able to fully support the ec2-ami tools.

Hopefully the euca2ools will improve over the next release cycle and be
more of a drop in replacement for the ec2-ami tools. In case you were not
aware, the images *do* have a 'euca-bundle-vol' command that is a
workalike to ec2-bundle-vol. There are open bugs on it, but euca2ools are
the ones we can support.

> 2. unstable mounted ebs volumes. for a couple days, i couldn't get my
> instances to consistently mount ebs volumes. after buying premium aws
> support and talking to a support rep on the phone, i realized that there
> were 2 reasons for this.

I'd have to look further into this. I don't see any obvious simple
changes that we could make to help out though.

Chris Ey

unread,
Dec 14, 2009, 6:19:07 AM12/14/09
to ec2u...@googlegroups.com
Hey Eric, Scott, et al,

thanks a lot for the migration. In fact I am in the process of setting up DB servers with MySQL and EBS following Eric's tutorial at
http://developer.amazonwebservices.com/connect/entry.jspa?externalID=1663

Unfortunately, the images I want to use all seem to have a problem with XFS and I get the following error:
$ sudo modprobe xfs
FATAL: Module xfs not found.

I am using the official Ubuntu Karmic 9.10 image, ami-7b3c6d3e in us-west-1. But I had the very same problem using ami-ab15f6c2 in us-east-1 and even when I used the daily build ami-c5217080 in us-west-1, it had the same problem.

I always made sure I installed xfsprogs before trying.

Am I missing something?

Thanks a lot
Chris



I get past the problem of US-WEST-1 with t

Eric Hammond

unread,
Dec 14, 2009, 7:10:00 AM12/14/09
to ec2u...@googlegroups.com
Chris:

XFS support is built in to the Ubuntu kernel on EC2, so that modprobe command is not needed.

--
Eric Hammond

Scott Moser

unread,
Dec 14, 2009, 9:09:44 AM12/14/09
to ec2u...@googlegroups.com
On Mon, 14 Dec 2009, Chris Ey wrote:

> Hey Eric, Scott, et al,
>
> thanks a lot for the migration. In fact I am in the process of setting
> up DB servers with MySQL and EBS following Eric's tutorial at
> http://developer.amazonwebservices.com/connect/entry.jspa?externalID=1663
>
> Unfortunately, the images I want to use all seem to have a problem with
> XFS and I get the following error:
> $ sudo modprobe xfs
> FATAL: Module xfs not found.
>
> I am using the official Ubuntu Karmic 9.10 image, ami-7b3c6d3e in
> us-west-1. But I had the very same problem using ami-ab15f6c2 in
> us-east-1 and even when I used the daily build ami-c5217080 in
> us-west-1, it had the same problem.

I just verified the following on ami-7b3c6d3e . It would be helpful if,
in the future you give a manifest path for the ami you list. ami-7b3c6d3e
doesn't really mean much to me, but if you say
ami-7b3c6d3e ubuntu-images-us-west-1/ubuntu-karmic-9.10-amd64-server-20091027.1.manifest.xml
Then I dont have to translate each ami id myself.

$ grep XFS /boot/config-$(uname -r)
CONFIG_XFS_FS=y
CONFIG_XFS_QUOTA=y
CONFIG_XFS_POSIX_ACL=y
CONFIG_XFS_RT=y
# CONFIG_XFS_DEBUG is not set
CONFIG_VXFS_FS=m

The big thing to note above is that XFS support is built into the kernel,
there is no need to 'modprobe xfs'

$ sudo apt-get update && sudo apt-get install xfsprogs
$ sudo sed -i s',us.ec2.archive.ubuntu.com,us-west-1.ec2.archive.ubuntu.com,g' /etc/apt/sources.list
$ sudo umount /mnt
$ sudo mkfs.xfs -f /dev/sdb
$ sudo mount /dev/sdb1 /mnt
$ time sudo rsync -a --one-file-system / /mnt/my-root
real 0m20.944s
$ sudo umount /mnt
$ sudo mount /mnt
$ sudo mount /dev/sdb /mnt

Generally functionl.

Scott

Daryoush Paknad

unread,
Dec 14, 2009, 12:51:19 PM12/14/09
to ec2u...@googlegroups.com
I have the same problem with Ubuntu Karmic 9.10 -- ami-1515f67c (us-east-1a).
Daryoush

--

Christian Ey

unread,
Dec 14, 2009, 12:51:38 PM12/14/09
to ec2u...@googlegroups.com
This is very helpful, thanks.
Will provide the manifest path in future as well, sorry.

Chris

"Scott Moser" <smo...@ubuntu.com> wrote:

>On Mon, 14 Dec 2009, Chris Ey wrote:
>
>> Hey Eric, Scott, et al,
>>
>> thanks a lot for the migration. In fact I am in the process of setting
>> up DB servers with MySQL and EBS following Eric's tutorial at
>> http://developer.amazonwebservices.com/connect/entry.jspa?externalID=1663
>>
>> Unfortunately, the images I want to use all seem to have a problem with
>> XFS and I get the following error:
>> $ sudo modprobe xfs
>> FATAL: Module xfs not found.
>>
>> I am using the official Ubuntu Karmic 9.10 image, ami-7b3c6d3e in
>> us-west-1. But I had the very same problem using ami-ab15f6c2 in
>> us-east-1 and even when I used the daily build ami-c5217080 in
>> us-west-1, it had the same problem.
>

>--
>You received this message because you are subscribed to the "ec2ubuntu" Google Group:
> http://groups.google.com/group/ec2ubuntu
>To unsubscribe, send email to ec2ubuntu-...@googlegroups.com

Sent from my Android phone with K-9. Please excuse my brevity.

bbulkow

unread,
Dec 15, 2009, 1:05:19 PM12/15/09
to ec2ubuntu
Hi, I had huge problems using the http://alestic.com/ us-west-1
images, and migrating the US images to the west.

I might not understand all the problems I ran into, but I think I do.
Since you people are so nice to try to bundle up my favorite releases,
I'm giving back with my information. I don't promise all of it's
correct.

The problems I had fell into three categories (one not the fault of
anyone on this list)

1) the API tools and AMI tools bundled with those images are several
versions behind, and don't support --location us-west-1 .
Perniciously, the tools don't have clear errors when there's a data
center they don't support (try migrating or registering in a location
like 'foobie' and see the inscrutable errors). And, the version of the
tools in the Ubuntu repository is too far behind to pick up the us-
west-1 changes. The hand-install route is a little painful, with
Amazon's README instructions slightly off the mark. Once I had these
tools to current, life was exceptionally good.

2) There is a massive lack of documentation regarding the ec2-migrate-
bundle and AKIs. When migrating a bundle, you need to choose the
correct AKI in the new location, but getting a list of AKIs is like
pulling hen's teeth (fiddly and error prone). Amazon's method requires
getting a list of AKIs through an ec3- API call, but that list doesn't
give any guidance between the three recent version 64-bit fedora-core
derived AKIs - and which AKIs require ARI, and which. There's a note
on one of the EC2 pages about being careful your AKI matches your boot
image, and how you should read the release notes for a given AKI, but
there's no source of these release notes from Amazon. If Amazon is
going to release AKIs to the community, there should be a location
where you can list the AKIs and get somewhat detailed release notes
(known issues like security holes and driver support), *or* people
providing community AMIs need to specify the AKIs the AMI is intended
to work with - because I need to specify AKI numbers when doing the
migrate.

3) The s3cmd tools I've been using (python version) don't support
bucket creation in the us-west-1 location. I suspect this is the same
FAIL as the ec2- API and AMI tools not understanding a new location
(wouldn't everyone just pass through to the REST calls?). I'm not sure
the Ruby s3cmd calls Amazon prefers is any better, perhaps it is. I
eventually got a proper us-west-1 bucket by doing a migrate into an
empty bucket, so I can now use that bucket for everything. Python
s3cmd at least will 'info' and tell me where my bucket is.

I'm not asking for fixes, just telling you my experiences. As EC2 will
likely be adding more datacenters every year (multiple? Singapore
+ ???), we're all getting to understand how these tools need some
better work. The biggest hang-up from my perspective is tools that
don't require revs when new data centers come online (maybe we're
already there; we won't know until Singapore comes online and the
tools either work or don't).

Thanks!

-brian

On Dec 3, 2:01 am, Chris Ey <e...@inweb.de> wrote:
> Hi there
>
> first of all "Hi" to everybody, I'm new to this forum and new to AWS in
> general (yeah, yet another newbie).
>
> I would like to set up EC2 instances with Ubuntu images in region
> "US-WEST-1" but when I view all available AMIs for this region with
> ubuntu as a platform I see none. I am able to play with instances in
> "US-EAST-1" though.
>
> Does this mean the Ubuntu AMIs have simply not been uploaded to region
> US-WEST-1 yet?
>
> Ah yeah, and I will be asking some questions about setting up a MySQL
> server with Ubuntu and EBS some time soon too; just in case you already
> can recommend a good image to start with. I thought maybe Ubuntu 9.04
> Jaunty might make sense as Eric Hammond created a nice tutorial for this

Scott Moser

unread,
Dec 15, 2009, 4:19:53 PM12/15/09
to ec2ubuntu
On Tue, 15 Dec 2009, bbulkow wrote:

> 1) the API tools and AMI tools bundled with those images are several
> versions behind, and don't support --location us-west-1 .
> Perniciously, the tools don't have clear errors when there's a data
> center they don't support (try migrating or registering in a location
> like 'foobie' and see the inscrutable errors). And, the version of the
> tools in the Ubuntu repository is too far behind to pick up the us-
> west-1 changes. The hand-install route is a little painful, with
> Amazon's README instructions slightly off the mark. Once I had these
> tools to current, life was exceptionally good.

Hopefully https://launchpad.net/~ubuntu-on-ec2/+archive/ec2-tools can
help. Up until today, it didn't have backports of the recent versions,
but it should have the lastest ami (2009-10-31/1.3-45758) and api
(2009-11-30/1.3-46266) tools very soon now.

Chuck started this 'backports' archive a while ago, and I didn't even know
if it until this week. Hopefully I can keep it reasonably current.

> 2) There is a massive lack of documentation regarding the ec2-migrate-
> bundle and AKIs. When migrating a bundle, you need to choose the
> correct AKI in the new location, but getting a list of AKIs is like
> pulling hen's teeth (fiddly and error prone).

I agree. At one point I had considered maintaining a file that could be
supplied to '--mapping-url' (see 'ec2-migrate-image --help'), but for some
reason I gave up on that. Our publishing scripts do not rely on
migrate-image picking a kernel, we explicitly set one.

The naming convention [1] for our buckets makes this require scripting, but at
at least it is defined. Basically, to find what kernel you need to use in
region R:
- get the manifest path of the kernel/ramdisk you're using
via ec2-describe-image
- get the manifest name for that kernel/ramdisk
- get the "base bucket name" for that kernel/ramdisk, which is obtained by
removing "L" from the end. "L" here is "location". Ie, buckets are
named:
<name>-us-west-1 , <name>-us, or <name>-eu
for us-west-1, us-east-1, eu-west-1 regions respectively. Future
buckets will be named <name>-<region> (as 'us-west-1' buckets are now)
- create the new bucket name using <name>-<region>/manifest-name for the new region
you're migrating to
- get the new aki/ari id in the target region via
ec2-describe-images --region r

The above makes it sound harder than it is, but I agree, it is error
prone. Maybe there is something to maintaining a mapping-url at least for
the ubuntu images.

> 3) The s3cmd tools I've been using (python version) don't support
> bucket creation in the us-west-1 location. I suspect this is the same
> FAIL as the ec2- API and AMI tools not understanding a new location
> (wouldn't everyone just pass through to the REST calls?). I'm not sure
> the Ruby s3cmd calls Amazon prefers is any better, perhaps it is. I
> eventually got a proper us-west-1 bucket by doing a migrate into an
> empty bucket, so I can now use that bucket for everything. Python
> s3cmd at least will 'info' and tell me where my bucket is.

I submitted a patch for this at [2]. Theres an explanation along with it.

> I'm not asking for fixes, just telling you my experiences. As EC2 will
> likely be adding more datacenters every year (multiple? Singapore
> + ???), we're all getting to understand how these tools need some
> better work. The biggest hang-up from my perspective is tools that
> don't require revs when new data centers come online (maybe we're
> already there; we won't know until Singapore comes online and the
> tools either work or don't).

I think we're a lot closer now. Before there was a third region, no one
was certain on the naming convention for region and location. With
us-west-1, Amazon essentially broke the legacy convention. So, now as
long as they keep location==region you wont run into issues like the s3cmd
in the future. Thats not to say that 'migrate' wont fail on the client
side.... Their old version actually had a client side list of known
regions :-(

--
[1] https://wiki.ubuntu.com/UEC/Images/NamingConvention
[2] http://sourceforge.net/mailarchive/forum.php?thread_name=alpine.DEB.2.00.0912101316040.31780%40brickies&forum_name=s3tools-general

brian bulkowski

unread,
Dec 15, 2009, 4:45:27 PM12/15/09
to ec2u...@googlegroups.com
Thanks Scott!

One thought.

Scott Moser wrote:
> On Tue, 15 Dec 2009, bbulkow wrote:
>
>> 1) the API tools and AMI tools bundled with those images are several
>> versions behind, and don't support --location us-west-1
> Hopefully https://launchpad.net/~ubuntu-on-ec2/+archive/ec2-tools can
> help. Up until today, it didn't have backports of the recent versions,
> but it should have the lastest ami (2009-10-31/1.3-45758) and api
> (2009-11-30/1.3-46266) tools very soon now.
>
Sounds interesting --- what would I do with that location? Can I add it
to the apt sources list?

Manually installing wasn't too bad, just a matter of unzipping and
manually dropping the files carefully into the right /usr/local
directories, and setting the EC_HOME (which, prior, didn't need to be
set or defaulted right).

Mostly the issue was *knowing* I had to do it. Images are published as
'us-west-1' images by Alestic with versions of API and AMI tools that
don't support us-west-1. An oversight which happens - lots of moving parts.

But knowing what I know now, if I was publishing such images as
'us-west-1', I would put a BIG HAIRY NOTE on those downloads saying
"don't expect to make your own AMIs from these images" or "manual update
tools!!" .

Cheers,
-brian

Scott Moser

unread,
Dec 15, 2009, 7:51:23 PM12/15/09
to ec2u...@googlegroups.com
On Tue, 15 Dec 2009, brian bulkowski wrote:

> Thanks Scott!
>
> One thought.
>
> Scott Moser wrote:
> > On Tue, 15 Dec 2009, bbulkow wrote:
> >
> >> 1) the API tools and AMI tools bundled with those images are several
> >> versions behind, and don't support --location us-west-1
> > Hopefully https://launchpad.net/~ubuntu-on-ec2/+archive/ec2-tools can
> > help. Up until today, it didn't have backports of the recent versions,
> > but it should have the lastest ami (2009-10-31/1.3-45758) and api
> > (2009-11-30/1.3-46266) tools very soon now.
> >
> Sounds interesting --- what would I do with that location? Can I add it
> to the apt sources list?

Expand the "Technical details about this PPA" twisty and it will tell you.
But yeah, basically you do something like:

$ cat > /etc/apt/sources.list.d/ec2-backports.list <<EOF
deb http://ppa.launchpad.net/ubuntu-on-ec2/ec2-tools/ubuntu karmic main
deb-src http://ppa.launchpad.net/ubuntu-on-ec2/ec2-tools/ubuntu karmic main
EOF

$ apt-get update && apt-get install ec2-api-tools ec2-ami-tools

PPA (Personal Package Archive) are quite handy things, you can read more
about them at https://help.launchpad.net/Packaging/PPA .

Scott

Eric Hammond

unread,
Dec 15, 2009, 8:22:11 PM12/15/09
to ec2u...@googlegroups.com
Brian:

Thanks for pointing out the problem with the Alestic AMIs on us-west-1.

When us-west-1 was released to the public I just migrated the old AMIs
from us-east-1 instead of building new ones, so the AMI tools do need to
be upgraded if you want to use newer features.

--
Eric Hammond

Symon

unread,
Dec 20, 2009, 11:26:19 AM12/20/09
to ec2ubuntu
On the same topic. I am getting an error after I've migrated an ubuntu
8.10 image to us-west-1. The migrate bundle went fine, and it is
registered, but when I try and run the instance, I cannot get to it.
I've tried starting the us-west-1 plain image and I can connect, but
not the ones I migrated.

I suspect from looking at the console output that it is a ssh key
problem.

/etc/init.d/rc: 317: /etc/rcS.d/S50ec2-ssh-host-key-gen: Permission
denied - is the error I see on the console

Just not sure how to fix it.

Regards,

Symon

Eric Hammond

unread,
Dec 28, 2009, 10:19:05 PM12/28/09
to ec2ubuntu
Symon:

The "Permission denied" warning is not important. It results from a
bad decision I made a long time ago about how to only run a startup
job once per instance.

Did you solve the migration issues? You might provide more details
about how you migrated them and perhaps a link to the entire console
output.

Other useful connectivity info is suggested here:
http://alestic.com/2009/08/ec2-connectivity

--
Eric Hammond

Reply all
Reply to author
Forward
0 new messages