usr-share-oem-cloud\x2dconfig.yml.service unit failure - ssh lockout

[TaiSHiNet]

Issue Report

Bug

Instance cannot be accessed for 10 minutes (services timeouts)

CoreOS Version

1180.0.0

$ cat /etc/os-release
NAME=CoreOS
ID=coreos
VERSION=1180.0.0
VERSION_ID=1180.0.0
BUILD_ID=2016-09-23-2100
PRETTY_NAME="CoreOS 1180.0.0 (MoreOS)"
ANSI_COLOR="1;32"
HOME_URL="https://coreos.com/"
BUG_REPORT_URL="https://github.com/coreos/bugs/issues"

Environment

What hardware/cloud provider/hypervisor is being used to run CoreOS?
AWS Instances (several sizes)

Expected Behavior

Boot up normally

Actual Behavior

Instances boot but cannot be accessed for 10~ minutes

Reproduction Steps

1. Boot instance with any custom userdata
2. Profit!

Other Information

CoreOS alpha (1180.0.0)
Failed Units: 1
system-cloudinit@usr-share-oem-cloud\x2dconfig.yml.service

Similar to #1562 #1559

[crawford]

I've paused automatic updates until we figure out what is going on. Glad to see that the new service timeout for coreos-cloudinit was useful -_-

[wmark]

In light of #1562, these are the differences between 1164.1.0 and 1180.0.0:

On 1180.0.0 no motd is shown.

Differences in files:

# /usr/lib/systemd/system/locksmithd.service, 1164.1.0 → 1180.0.0
+ Requires=update-engine.service
+ After=update-engine.service user-config.target system-config.target

Then system-config.target contains Requires=system-cloudinit@usr-share-oem-cloud\x2dconfig.yml.service which in turn, I guess, restarts locksmithd (shouldn't it be just reload or try-restart?). ⚪

[crawford]

The commit mentioned above fixes the issue. When I fixed this the first time, I backported it to the Alpha at the time but forgot to fix it in the master branch. We should have a new image later today.

[TaiSHiNet]

Thanks for the speed!

[crawford]

CoreOS Linux 1185.0.0 is now available with the fix. We'll begin rolling it out shortly. Thanks for your patience.