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