robyn.bergeron at gmail.com
Fri Mar 30 21:00:52 UTC 2012
On Fri, Mar 30, 2012 at 1:54 PM, Andy Grimm <agrimm at gmail.com> wrote:
> On Thu, Mar 29, 2012 at 7:53 PM, Heherson Pagcaliwagan
> <herson at azneita.org> wrote:
>> On Fri, Mar 30, 2012 at 7:39 AM, Heherson Pagcaliwagan
>> <herson at azneita.org> wrote:
>>> On Thu, Mar 29, 2012 at 8:48 PM, Garrett Holmstrom
>>> <gholms at fedoraproject.org> wrote:
>>>> On Mar 28, 2012 9:06 PM, "Heherson Pagcaliwagan" <herson at azneita.org> wrote:
>>>>> On Thu, Mar 29, 2012 at 12:22 AM, Dennis Gilmore <dennis at ausil.us> wrote:
>>>>> > i have uploaded a x86_64 image to us-east-1 in ec2 the ami is
>>>>> > ami-3fb16f56 for whatever reason that i can not yet figure out the
>>>>> > image is booting fine but ssh will not allow me to connect. ive stopped
>>>>> > the image and attached it to a f16 instance and examined the disk and
>>>>> > it all looks fine. with the ssh logs just saying that the client
>>>>> > disconnected.
>>>>> > Id appreciate if some people could have a look and see if its working
>>>>> > for them or help diagnose what exactly is going on.
>>>>> Not sure if this is it, but I did not see a /root/.ssh/authorized_keys
>>>> This is expected. Look for it under /home/ec2-user instead.
>>> Thanks Garret. It did not occur to me to check the entire contents of
>>> /home/ and solely relied on the web console's "Connect to Instance"
>>> hint. Will try again later :)
>>>> Of course, if it isn't there either then there may be a problem. ;-)
>> Now this is fun. Yup, no authorized_keys file on under /home/ec2-user.
> Right, I see the same thing. authorized_keys is not being populated.
> Here's my guess. On working F16, I see:
> Mar 30 15:43:24 localhost cloud-init: ci-info: lo : 1
> 127.0.0.1 255.0.0.0
> Mar 30 15:43:24 localhost cloud-init: ci-info: eth0 : 1
> 10.245.187.79 255.255.254.0 12:31:3d:01:b8:a1
> Mar 30 15:43:24 localhost cloud-init: ci-info: route-0: 0.0.0.0
> 10.245.186.1 0.0.0.0 eth0 UG
> Mar 30 15:43:24 localhost cloud-init: ci-info: route-1:
> 10.245.186.0 0.0.0.0 255.255.254.0 eth0 U
> Mar 30 15:43:24 localhost cloud-init: ci-info: route-2:
> 169.254.0.0 0.0.0.0 255.255.0.0 eth0 U
> On F17, I see:
> Mar 30 15:27:12 localhost cloud-init: ci-info: route-0: 0.0.0.0
> 10.80.210.1 0.0.0.0 eth0 UG
> Mar 30 15:27:12 localhost cloud-init: ci-info: route-1:
> 10.80.210.0 0.0.0.0 255.255.254.0 eth0 U
> Of those differences, I suspect that lack of a zeroconf route
> (169.254.0.0/16) is probably preventing access to the metadata
> service. Further, I believe the reason is related to the addition of
> NetworkManager in the F17 AMI (because the zeroconf route is typically
> added via the ifcfg-eth script, which NM does not run). Before I go
> hacking further, is there a particular reason that we switched to
> using NetworkManager in the F17 AMI?
> Would removing it be the wrong solution, and if so, is there a quick
> way to ensure that NM initializes a zeroconf route?
Hmmm, I wonder if it's loosely related to this:
(See details in comments, it has something to do with something new in
comps, libvirt, networkmanager, other fun stuff.)
> cloud mailing list
> cloud at lists.fedoraproject.org
More information about the cloud