Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 16 Jun 2015 23:13:58 +0100
From:      Carsten Heesch <ch@sysconfig.org.uk>
To:        freebsd-cloud@freebsd.org
Subject:   Re: EC2 AMIs will be available from snapshot builds
Message-ID:  <55809FA6.7020705@sysconfig.org.uk>
In-Reply-To: <55808FD0.8050203@freebsd.org>
References:  <55512E50.7010702@freebsd.org> <20150616134619.GB97471@mouf.net> <20150616160340.GB1387@hub.FreeBSD.org> <20150616183423.GB21206@mouf.net> <20150616184748.GA43498@gmail.com> <5580751A.4060306@freebsd.org> <20150616203338.GA48451@gmail.com> <55808FD0.8050203@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help


On 16/06/2015 22:06, Colin Percival wrote:
> On 06/16/15 13:33, Collin Forbes wrote:
>> On Tue, Jun 16, 2015 at 12:12:26PM -0700, Colin Percival wrote:
>>> On 06/16/15 11:47, Collin Forbes wrote:
>>>>
>>>> I was seeing this with ami-53fcb763 over the weekend. That one isn't a
>>>> even a snapshot release. It's the AMI for FreeBSD 10.1-RELEASE for current
>>>> generation instances on us-west-2. I was trying to use t2.small and
>>>> t2.medium instances and had the same behavior.
>>>
>>> Works for me... takes about 5 minutes before you can SSH in though, since the
>>> image downloads security patches first.
>>
>> I've attached a copy/paste from the system log of an instance I just
>> tried launching.  It was a t2.small with ami-53fcb763 (10.1-RELEASE)
>>
>> I have a note about behavior in the middle of the log. It seems to hang at:
>>
>>     freebsd-update: Fetching public key from update6.freebsd.org... failed.
> 
> This isn't a hang... not really.  The EC2 console has the annoying property
> of not being real-time; the console gets read a few minutes after the instance
> boots, and that gets cached for later console-read requests.
> 
>> I waited about 15 minutes and then gave it a reboot command from the AWS
>> console. The remaining lines appeared in the log after that. However, the
>> instance is not accessible after the reboot and there are no other log
>> lines indicating the instance rebooted.
> 
> ... meanwhile the EC2 instance (slowly) continues on, trying and failing to
> contact all the other freebsd-update mirrors, but that output doesn't appear
> until the instance is rebooted or shut down (at which point the EC2 console
> refreshes itself).
> 
> The same thing is going on with Steve's "hanging after 'Fetching EC2
> user-data failed'": The thing which happens after that in the boot process
> is the pkg bootstrap, which is taking a long time before it fails.
> 
> I managed to replicate this problem in two ways:
> 
> 1. Launching an instance without a public IP address.
> 
> 2. Launching an instance *with* a public IP address, but into a VPC subnet
> which didn't have a route to the rest of the internet.  I have absolutely
> no idea how this happened...
> 
> In any case, make sure that your EC2 instance has a public IP address and
> the VPC subnet it's in has a default route.
> 


I have tested ami-031b6674 and ami-2d1b665a (eu-west-1) today, and they
work just fine within a so-called private subnet (connecting outbound
through nat instance) and no public IP.

A valid default route through an "igw" (gateway) or via a working nat
instance is all that's needed, I think.

If it's via igw, the instance must have a public IP. If it's behind a
NAT instance, the instance must not have a public IP (it will implicitly
override the default nat route otherwise, and lead nowhere). Don't know
why Amazon even allow EIPs in subnets that don't have a direct route to
world.


On a side note, I'd like to thank Colin, Glen and everybody else
involved in making FreeBSD usable in AWS! This is really good stuff, and
the huge effort that has gone into it is much appreciated!


Cheers
Carsten





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55809FA6.7020705>