Ben Cressey

I'm still seeing "fresh" crates across consecutive builds of the `os` package, as long as sources don't change. So I expect this is still a potential bug.

Fixed in https://github.com/bottlerocket-os/bottlerocket-core-kit/pull/20

This is the OVF change in isolation: ``` diff --git a/variants/shared/template-unified-secboot.ovf b/variants/shared/template-unified-secboot-tpm.ovf index a6df2e2ec..dd932b5f8 100644 --- a/variants/shared/template-unified-secboot.ovf +++ b/variants/shared/template-unified-secboot-tpm.ovf @@ -69,6 +69,13 @@ + + true + Virtual TPM +...

Can you provide more details on your use case? Are you trying to use a single user-data document to provision either Amazon Linux or Bottlerocket? Seems like there's a standard...

Bottlerocket doesn't package the k8s control plane software like `kube-apiserver` and `etcd`, those are configured by EKS-A.

On the Bottlerocket side, the `cloud-provider` field is only used as part of the [kubelet-exec-start-conf](https://github.com/bottlerocket-os/bottlerocket-core-kit/blob/develop/packages/kubernetes-1.34/kubelet-exec-start-conf) template, which controls how `kubelet` starts. It doesn't propagate upwards from there into pods, or...

kubelet wouldn't and can't really do that. It'd have to be a flow where the EKS-A cluster bootstrap code used the value of that Bottlerocket setting when configuring the apiserver...