Terraform v1.3.4 darwin_amd64 installed on Mac M2 with arm64

Terraform
1

Hi guys, recently I was struggling against version incompatible problem between local environment and terraform version, which gave me a good lesson learn. I really want to share with you all who are exploring on Terraform.

I’m working on an OLD terraform project that deploys AWS resources. For some historical reason, the required terraform version is 1.3.4. And my laptop is Mac Air M2. As the M2 OS is arm64, I installed * terraform_1.3.4_darwin_arm64.zip on Mac, but failed to install providers with below error messages when running “terraform init”. However, I did found the darwin_arm64 version for all providers except for template which is deprecated officially. Anyway, as my understanding, it should install these providers that has an available darwin_arm64 release(version) successfully.

Finally, I found a workaround which is surprised me and confused me as well. I reinstalled terraform v1.3.4_darwin_amd64 instead of v1.3.4_darwin_arm64, and all providers got installed successfully, of course amd64 version.

It never enter my mind that if I can try another terraform version on Mac OS. Terraform provides a list of zip files for almost all OS for each version, like Terraform v1.3.4 Binaries | HashiCorp Releases , it gives me a sense that your OS is linux, you go linux, if your OS is windows, you take windows, for me, of course, it’s arm64.

Sometimes, we have to break our thinking set and try something that may be crazy. Then you will find a solution…

this backend unless the backend configuration changes.

Initializing provider plugins...
- terraform.io/builtin/terraform is built in to Terraform
- Reusing previous version of hashicorp/local from the dependency lock file
- Reusing previous version of hashicorp/archive from the dependency lock file
- Reusing previous version of hashicorp/null from the dependency lock file
- Reusing previous version of hashicorp/aws from the dependency lock file
- Reusing previous version of hashicorp/template from the dependency lock file
- Installing hashicorp/local v2.2.3...
- Installed hashicorp/local v2.2.3 (signed by HashiCorp)
╷
│ Warning: Version constraints inside provider configuration blocks are deprecated
│ 
│   on providers.tf line 5, in provider "aws":
│    5:   version = "~> 2.62"
│ 
│ Terraform 0.13 and earlier allowed provider version constraints inside the provider configuration block, but that is now deprecated and will be removed in a future version of Terraform. To silence this warning, move the
│ provider version constraint into the required_providers block.
│ 
│ (and 4 more similar warnings elsewhere)
╵

╷
│ Error: Incompatible provider version
│ 
│ Provider registry.terraform.io/hashicorp/aws v2.70.1 does not have a package available for your current platform, darwin_arm64.
│ 
│ Provider releases are separate from Terraform CLI releases, so not all providers are available for all platforms. Other versions of this provider may have different platforms supported.
╵

╷
│ Error: Incompatible provider version
│ 
│ Provider registry.terraform.io/hashicorp/template v2.2.0 does not have a package available for your current platform, darwin_arm64.
│ 
│ Provider releases are separate from Terraform CLI releases, so not all providers are available for all platforms. Other versions of this provider may have different platforms supported.
╵

╷
│ Error: Incompatible provider version
│ 
│ Provider registry.terraform.io/hashicorp/archive v1.3.0 does not have a package available for your current platform, darwin_arm64.
│ 
│ Provider releases are separate from Terraform CLI releases, so not all providers are available for all platforms. Other versions of this provider may have different platforms supported.
╵

╷
│ Error: Incompatible provider version
│ 
│ Provider registry.terraform.io/hashicorp/null v2.1.2 does not have a package available for your current platform, darwin_arm64.
│ 
│ Provider releases are separate from Terraform CLI releases, so not all providers are available for all platforms. Other versions of this provider may have different platforms supported.
╵

╷
│ Error: Required plugins are not installed
│ 
│ The installed provider plugins are not consistent with the packages selected in the dependency lock file:
│   - registry.terraform.io/hashicorp/aws: there is no package for registry.terraform.io/hashicorp/aws 2.70.1 cached in .terraform/providers
│   - registry.terraform.io/hashicorp/local: the cached package for registry.terraform.io/hashicorp/local 2.2.3 (in .terraform/providers) does not match any of the checksums recorded in the dependency lock file
│   - registry.terraform.io/hashicorp/null: there is no package for registry.terraform.io/hashicorp/null 2.1.2 cached in .terraform/providers
│   - registry.terraform.io/hashicorp/template: there is no package for registry.terraform.io/hashicorp/template 2.2.0 cached in .terraform/providers
│   - registry.terraform.io/hashicorp/archive: there is no package for registry.terraform.io/hashicorp/archive 1.3.0 cached in .terraform/providers
│ 
│ Terraform uses external plugins to integrate with a variety of different infrastructure services. To download the plugins required for this configuration, run:
│   terraform init
2

Hi @camillehe1992,

Thanks for sharing what you learned!

The reason this works is due to a feature of macOS rather than a feature of Terraform: current versions of macOS for Apple Silicon include a component called “Rosetta 2” which acts as an emulator of an amd64 CPU, dynamically translating that machine code to arm64 machine code at runtime.

Because this is implemented as software emulation it may not work 100% correctly in all cases, but lots of folks have reported it being sufficient for them to get Terraform working enough to upgrade their older provider versions to a more modern set of versions.

It isn’t certain that Rosetta 2 will be supported forever, so I would suggest prioritizing upgrading all of your providers to versions that were released with darwin_arm64 support as soon as possible. Emulation is a useful way to perform those upgrades without needing to use a real amd64 CPU, but provider developers don’t typically test providers thoroughly in the Rosetta 2 environment and so there may be bugs that would not occur if running the providers directly on the CPU.

1 Like
3

@apparentlymart thanks for your reply. That’s really helpful

4

Hi, has this been resolved in 1.5.x?

5

Hi @sanjay.jairam.eu,

This topic was discussing strategies for moving away from an end-of-life providers while using a platform that didn’t exist at that provider’s last release.

Everything discussed here is still true: the provider is still end-of-life, its most recent release predates the existence of darwin_arm64, and Rosetta emulation is still available in macOS that might help to use the darwin_amd64 build to complete a migration.

The only way I’d expect this situation to evolve in future is that Apple might stop supporting Rosetta emulation, in which case that migration workaround would no longer be effective. Therefore I would suggest moving away from the unsupported provider as soon as possible, while that workaround is still available.