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
