Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cloud-init instance crash with MIMEBOUNDARY userdata #2588

Open
Deshke opened this issue Jun 3, 2019 · 1 comment

Comments

Projects
None yet
3 participants
@Deshke
Copy link

commented Jun 3, 2019

Issue Report

Bug

Container Linux Version

https://coreos.com/releases/#2079.4.0

Environment

AWS EC2 m5.* c5.*

Expected Behavior

instance boots and is usable with multipart user-data

Actual Behavior

Bildschirmfoto vom 2019-06-03 15-24-36

the instance is stuck in boot and does not recover

Reproduction Steps

  1. start a ec2 instance with a user-data script with MIMEBOUNDARY content type
Content-Type: multipart/mixed; boundary="MIMEBOUNDARY"
MIME-Version: 1.0

--MIMEBOUNDARY
Content-Disposition: attachment; filename="nodeup.sh"
Content-Transfer-Encoding: 7bit
Content-Type: text/x-shellscript
Mime-Version: 1.0

#!/bin/bash

echo "some fancy script here"

--MIMEBOUNDARY--
  1. see screenshot from actual behavior

Other Information

stumbled upon this while trying to use the kops mixed isntance types / spot fleet
https://github.com/kubernetes/kops/blob/master/docs/instance_groups.md#creating-a-instance-group-of-mixed-instances-types-aws-only

the launch template contains the Content-Type: multipart/mixed; boundary="MIMEBOUNDARY" but somehow coreos-cloudinit can not parse the data. After manually updating the launch template the spot-fleet is usable but any kops(https://github.com/kubernetes/kops/releases/tag/1.12.1 ) update will negate this. Strangely enough this works with the ubuntu LTS image

@crawford

This comment has been minimized.

Copy link
Member

commented Jun 3, 2019

coreos-cloudinit is not the same as Canonical's Cloud-Init and doesn't support MIME messages; YAML and scripts only. As a result, Ignition (the replacement for coreos-cloudinit) also doesn't understand that this is intended for coreos-cloudinit and so it tries and fails to parse it. That's what's causing your reboot loop.

coreos-cloudinit has been deprecated for a while now. You should try to migrate to Ignition instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.