Re: help needed

[Robyn Bergeron <robyn.bergeron@xxxxxxxxx>]

On Fri, Mar 30, 2012 at 2:00 PM, Robyn Bergeron
<robyn.bergeron@xxxxxxxxx> wrote:
> On Fri, Mar 30, 2012 at 1:54 PM, Andy Grimm <agrimm@xxxxxxxxx> wrote:
>> On Thu, Mar 29, 2012 at 7:53 PM, Heherson Pagcaliwagan
>> <herson@xxxxxxxxxxx> wrote:
>>> On Fri, Mar 30, 2012 at 7:39 AM, Heherson Pagcaliwagan
>>> <herson@xxxxxxxxxxx> wrote:
>>>> On Thu, Mar 29, 2012 at 8:48 PM, Garrett Holmstrom
>>>> <gholms@xxxxxxxxxxxxxxxxx> wrote:
>>>>> On Mar 28, 2012 9:06 PM, "Heherson Pagcaliwagan" <herson@xxxxxxxxxxx> wrote:
>>>>>>
>>>>>> On Thu, Mar 29, 2012 at 12:22 AM, Dennis Gilmore <dennis@xxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx
>> https://admin.fedoraproject.org/mailman/listinfo/cloud
_______________________________________________
cloud mailing list
cloud@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/cloud