If you have a configuration that was previously working on darwin_amd64 (that is, macOS on Intel chips) then I’ve heard that it typically works okay to run the darwin_amd64 version of Terraform under Rosetta emulation just long enough to remove the obsolete provider – darwin_amd64 Terraform CLI will install and run darwin_amd64 providers – and then you can switch back to using the native darwin_arm64 port of Terraform CLI and providers once you’ve completed that update.
Once you no longer have any data "template_file" ... blocks in your configuration anymore you can run terraform apply or terraform apply -refresh-only to create a new state snapshot that doesn’t refer to that provider, after which you will no longer need to use the darwin_amd64 port.
You may need to also use newer versions of other providers to get darwin_arm64 compatibility, depending on how long ago you last upgraded them. If so, you can also complete those upgrades also using the darwin_amd64 port under emulation. As long as your .terraform.lock.hcl file selects a sufficiently-new version and includes all of the official cross-platform checksums for that version then darwin_arm64 Terraform should be able to install and use it.
I’d love to be able ot use the @apparentlymart method, since it seems like the cleanest solution to me. I’m happy to switch to the templatefile() function.
So I’ve replaced all instances of the template_file provider with the templatefile() function. I’ve then opened a Rosetta terminal and confirmed that it’s running under emulation (arch responds with i386). When I use terraform init, though, I still get the no package available for your current platform, darwin_arm64 error.
Does the fact that I’m using Terraform Cloud factor into this at all? I tried removing the template provider block entirely from my .terraform.lock.hcl and that changed nothing. I’m kind of stumped at this point. I thought I knew what the problem was, but this isn’t behaving like I’d expect.
So the solution in my case was to make the template_file to templatefile() change on the Intel Mac and apply the changes so that Terraform Cloud no longer needed the provider. Then I was able to run terraform init again and the lockfile was updated, removing the provider. I checked that in on the Intel Mac and fetched it on the M1. Now terraform init on the M1 Mac works fine.
It’s pretty much what @apparentlymart suggested, just using a real Intel Mac instead of emulation. Thanks for explaining what the underlying issue was!
Hi Nick, I had the same problem after switching to templatefile(), and it terraform init still trying to download template provider, it turns out in my current state still has the data.template_file resources, what I have done is to remove them from the state file by getting all the template_file resources from the current state by running terraform state list | grep data.template_file
then remove one by one using terraform state rm <resource_name>
By giving a try to these different answers, here is what I ran to install a Terraform 1.3.3 version that works under my Mac M1 and get rid of this error:
I agree with @stuart-c - For those landing on this article in 2022/2023, please, make sure you stop using the Template Provider as it has been deprecated.
$ m1-terraform-provider-helper install hashicorp/template -v v2.2.0
Getting provider data from terraform registry
Getting source code...
FATA[0001] Bash execution did not run successfully: exit status 1.
Output:
Im Moment auf keinem Branch.
Bitte geben Sie den Branch an, welchen Sie zusammenführen möchten.
Siehe git-pull(1) für weitere Details.
git pull <Remote-Repository> <Branch>
I know this is an old post. However, I think this might be helpful for someone.
Like @lpossamai2 said in his comment above, don’t use template_file anymore and replace it with templatefile in all your modules. Then run the following:
rm -rf .terraform
rm -f .terraform.lock.hcl
terraform init # this one will fail again, with the same error as above, but it will give you access to the state
for i in `terraform state list | grep template_file`; do terraform state rm $i; done
terraform init # this one will work now
terraform apply
Just make sure you have replaced your template_file in all your modules. Otherwise, you will hit the same problem. And check the state before you run the for loop, just in case you called any resource/module a template_file
ok so this is weird. just ran a terraform plan/apply Terraform 0.14.4 on my m1 Ventura Version 13.2 (22D49) and it worked even though the template provider has not been updated to dawin_arm64 : Terraform Provider Template v2.2.0 Binaries | HashiCorp Releases
Hi, for us any of it did not work (except crippling template_file plugin worked, but it is not really nice solution). We removed all references to template_file from code which left empty references in state file for some reason, e.g.
Which did not pose any issue on non-darwin_arm64 terraform binaries, but on M1 it fails. There is no clean way to fix this issue, but to go to state file and remove these empty references manually. They do not appear in terraform state list so there is really nothing to do. This seems like rather critical bug to me
Terraform’s code normally removes these resource blocks when the instances collection becomes empty. If you are able to figure out a sequence of operations which leaves one behind like this, that would be worth a bug report.
