On Fri, Mar 30, 2012 at 2:00 PM, Robyn Bergeron
<robyn.bergeron(a)gmail.com> wrote:
On Fri, Mar 30, 2012 at 1:54 PM, Andy Grimm <agrimm(a)gmail.com>
wrote:
> On Thu, Mar 29, 2012 at 7:53 PM, Heherson Pagcaliwagan
> <herson(a)azneita.org> wrote:
>> On Fri, Mar 30, 2012 at 7:39 AM, Heherson Pagcaliwagan
>> <herson(a)azneita.org> wrote:
>>> On Thu, Mar 29, 2012 at 8:48 PM, Garrett Holmstrom
>>> <gholms(a)fedoraproject.org> wrote:
>>>> On Mar 28, 2012 9:06 PM, "Heherson Pagcaliwagan"
<herson(a)azneita.org> wrote:
>>>>>
>>>>> On Thu, Mar 29, 2012 at 12:22 AM, Dennis Gilmore
<dennis(a)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
>>>>> file.
>>>>
>>>> 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[748]: ci-info: lo : 1
> 127.0.0.1 255.0.0.0
> Mar 30 15:43:24 localhost cloud-init[748]: 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[748]: 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[748]: 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[748]: 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[543]: 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[543]: 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:
https://bugzilla.redhat.com/show_bug.cgi?id=802475
(See details in comments, it has something to do with something new in
comps, libvirt, networkmanager, other fun stuff.)
Actually, don't mind me, the stuff that changed changed very recently
(between rc1 and rc2) so I think this wouldn't necessarily be the root
of the problem, since we've been looking at this for a while.
>
> --Andy
> _______________________________________________
> cloud mailing list
> cloud(a)lists.fedoraproject.org
>
https://admin.fedoraproject.org/mailman/listinfo/cloud