It seems that Fedora 28 Atomic Beta (and F28 Beta Cloud) when using private IPs only, does not connect to the network. This results in the EC2 instance failing it's connectivity test and you cannot connect to it via SSH. If you test the AMI with a Public IP however, it will work just fine.
This was tested with the Fedora-AtomicHost-28_Beta-1.3.x86_64-us-west-2-HVM-gp2-0 (ami-e5841f9d) AMI. I detached the failed EC2 instance's EBS volume and attached it to a working server to dump the cloud-init.log and the systemd journal. You can download them here.
https://www.solidadmin.com/atomic/f28atomic-cloud-init https://www.solidadmin.com/atomic/f28atomic-journal
I have included the Fedora 28 Cloud logs as well if they will help.
https://www.solidadmin.com/atomic/f28cloud-cloud-init https://www.solidadmin.com/atomic/f28cloud-journal
The links to the logs are throwing 403 to me.
@sayanchowdhury Sorry about that. Mod_security thought it was being helpful. Try these:
did this work for f27?
Yes, F27 works fine. We have 50+ servers running F27 in right now and they pull an internal IP just fine.
To rule out any edge cases that maybe present from how my work sets up VPCs, I spun up a VM in us-east-1 with the default VPC and the result was the same. You can see below the instance is failing 1/2 checks and you cannot SSH to the machine over the private IP.
<img alt="Screenshot_from_2018-04-18_09-54-10.png" src="/atomic-wg/issue/raw/files/97448e902163677c4579142841dfa0843902c6ef3598b0bfc2a46d7d7f98c738-Screenshot_from_2018-04-18_09-54-10.png" />
I just noticed that the above screenshot was for Cloud. Here is the same test for Atomic in a default VPC failing it's Instance Status Check.
<img alt="Screenshot_from_2018-04-18_11-04-53.png" src="/atomic-wg/issue/raw/files/f08ebd9f8e1e811aa1389b3dc7c01705563b8678ed19be75569d07f81d7ff7ff-Screenshot_from_2018-04-18_11-04-53.png" />
Looks like cloud-init is setting BOOTPROTO=none for some reason.
BOOTPROTO=none
[fedora@worker ~]# cat /mnt/f28/etc/redhat-release Fedora release 28 (Twenty Eight) [fedora@worker ~]# cat /mnt/f28/etc/sysconfig/network-scripts/ifcfg-eth0 # Created by cloud-init on instance boot automatically, do not edit. # BOOTPROTO=none DEVICE=eth0 HWADDR=06:83:72:56:7c:66 ONBOOT=yes TYPE=Ethernet USERCTL=no
[fedora@worker ~]$ cat /etc/redhat-release Fedora release 27 (Twenty Seven) [fedora@worker ~]$ cat /etc/sysconfig/network-scripts/ifcfg-eth0 # Created by cloud-init on instance boot automatically, do not edit. # BOOTPROTO=dhcp DEVICE=eth0 HWADDR=02:71:be:de:7b:e6 ONBOOT=yes TYPE=Ethernet USERCTL=no
interesting.. I wonder if this upstream commit (first released in cloud-init 17.2) might fix the issue?
17.2
Using the patch from the upstream commit above resulted in no change.
Opened https://bugzilla.redhat.com/show_bug.cgi?id=1569321 per @dustymabe's request.
Reverting to cloud-init-0.7.9-9.fc27.noarch fixes the issue and allows the EC2 instance to DHCP:
cloud-init-0.7.9-9.fc27.noarch
[jdoss@sts71 ~]$ ssh fedora@10.0.11.156 Warning: Permanently added '10.0.11.156' (ECDSA) to the list of known hosts. [fedora@ip-10-0-11-156 ~]$ cat /etc/redhat-release Fedora release 28 (Twenty Eight) [fedora@ip-10-0-11-156 ~]$ rpm -qa |grep cloud-init cloud-init-0.7.9-9.fc27.noarch
BZ1569321 has been resolved now and is fixed in the f28 release going out tomorrow.
Metadata Update from @dustymabe: - Issue tagged with: bug, host
Metadata Update from @dustymabe: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.