There’s a terraform package for Termux (using a Galaxy Tab 7+). And most (all?) providers should work for the “linux_arm64” platform on this device. I’ve used:
terraform providers lock -platform=linux_arm64
to create locks for it. However, when I try a terraform init with that, I still get:
Provider Terraform Registry v4.31.0 does not have a package available for your current platform, android_arm64
Looks like the forum replaces uri looking things with the title of the url. Trying again for the correct error message:
Provider registry.terraform.io/hashicorp/aws v4.31.0 does not have a package available for your current platform, android_arm64
Hi @sandboxcom,
While android is based on the Linux kernel, the compilation target is different for their respective binaries. I’m not sure how the Terraform package you are using is compiled, but the android_arm64 runtime would need to be specified by default, and that is why it’s searching for android in the registry.
Unfortunately the terraform trace output doesn’t include the GOOS_GOARCH info, since that is usually obvious from the running host. Can you confirm that you can actually run a linux_arm64 Terraform binary?
From some occasional previous chatter about this, I remember that Termux is a Debian-derived Linux distribution that is built using Android-oriented compiler toolchains.
I see that Termux has Go toolchain packages: Index of /apt/termux-main/pool/main/g/golang/
…and so I assume that the Terraform packages are in turn built from those Go toolchains: Index of /apt/termux-main/pool/main/t/terraform/
There’s a build script for the Terraform packages here: termux-packages/build.sh at 40c3321f591fea3adbf8c137e513cd2195218905 · termux/termux-packages · GitHub
Since Android is not one of our supported platforms I don’t have any experience with what, if anything, is different in the Android port of Go as compared to the Linux port. I suppose it is possible in principle that the Linux builds could work, but in the Go repository I see a lot of special cases for Android in the startup code, in the OS API code, and in how exactly the Go tool runs the compiler. Given that, it may not be possible to run linux_arm64 executables on android_arm64.
Official support for different platforms is decided by the individual provider developers because they are the ones that create and sign their official distribution packages. You may be able to convince some developers to support android_arm64, but I expect not enough of them for Terraform to be generally useful in Termux.
I think there are some alternative paths that might be more profitable:
-
Try downloading a
linux_arm64package of Terraform, extract it into your Termux environment, and see if it will run at all there. For example, Terraform v1.2.9 forlinux_arm64.Just downloading and extracting the zip file and running the executable inside is a low-ceremony way to see if Linux executables produced by the Go toolchain seem binary-compatible with the Termux environment. You might find that these executables won’t start up at all, or you might find that they work but behave strangely. If you see it working well enough alone, you could then try running
./terraform initin a configuration which depends on a provider, which will cause that build of Terraform to downloadlinux_amd64provider packages which you can then try in a similar way.If that works for you then you could continue to use Terraform on Termux in that way and just ignore the packages available in the Termux repository.
-
If providers do need to be built specifically for Android, it would be possible in principle to include them in the Termux package archive as additional
.debpackages. (Though I don’t know if they would be accepted by the Termux maintainers; their own repository policies will apply here.)If Termux would be open to accepting such packages then I would suggest packaging in this way:
-
Place the built executables under
/usr/share/terraform/pluginsusing the unpacked provider package layout, which is one of the directories where Terraform will look for locally-installed providers before consulting the registry. -
Package the providers with package names that include at least their minor version number, so that it’s possible to select which version to install and to install multiple versions at once when needed.
If a package is just named e.g.
terraform-provider-hashicorp-aws(to representhashicorp/aws) then it wouldn’t be possible to install more than one version of it at a time, which is likely to be inconvenient if you work with many different Terraform configurations that have differing requirements. Calling itterraform-provider-hashicorp-aws-4.31would in principle allow installing multiple minor versions at the same time inside your Termux environment.
This would then allow e.g.
apt install terraform-provider-hashicorp-aws-4.31to install a version of thehashicorp/awsprovider, whichterraform initwill then find locally and therefore skip trying to ask the origin registry.However, this doesn’t address the issue of package checksums: no existing lock file will include the checksum of a Termux package and
terraform initrun for the first time under Termux will only be able to record the Termux checksum. To create a configuration that can be used both on supported platforms and in Termux will require some unusual extra steps to ensure that all of the needed checksums appear in your lock file. -
I’m trying to figure out how to manually install providers now (a local fs cache looks simple enough but that’s unlikely to get me around my platform issue). I’ve looked into the fedora and debian proot’s and they seem to want the same binary, so… This is the file information from my terraform binary and it looks like the one hashicorp officially compiles (maybe not - I don’t have another arm64 platform to look at, but it looks like it):
data/data/com.termux/files/usr/bin/terraform: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /system/bin/linker64, Go BuildID=ocZgbrHcOvobI1MwXEfe/oDtyOITye6ByoLgA9VWF/cXIh1zeb6gI8kX_Ov1gP/g0Dpd3ysg7pjQjybsZoA, stripped
This is why I just wanted a way to specify my architecture - it should just work. I’m going to continue down the path of trying to manually install the provider and ensure that works as an actual test though.
Without executing the binary, I’m not sure offhand how to differentiate android from vanilla linux, since they are both going to be the same binary format just with some differences in runtime. I do know however that is not an official Hashicorp binary release, since it’s dynamically linked. The goal with asking if you could run a normal linux binary above was to allow you to also run the linux provider binaries. There are not going to be android builds of most of the providers, so on top of manually installing them, you would also have to compile them all yourself.
It would appear you have a point and the binary I installed does have specific calls the hashicorp binary doesn’t:
Ah, interesting! I suppose on Android there must be a different mechanism for making network requests to allow Android to implement its application sandbox and permissions system, and so presumably one effect of building a Go application for Android is using a different implementation of the net package which does whatever is required to successfully access the network from an Android application.
Of course the main purpose of most Terraform providers is to access an API over the network, so this seems like a show-stopper: Terraform providers built for plain Linux will presumably encounter a similar problem as soon as they make an API request.
I think that means your only option is to build the providers inside your Termux environment yourself using the Termux Go toolchain, or to convince Termux upstream to include them in the distribution as I was describing. Your custom builds will then hopefully be able to interact with the Android network stack.
Yeah. Thank y’all for the help. I thought termux was using the official arm64 package out of the box. It’s not and I’m not trying to deploy android tablets to admin with right now, so a terraform + provider build pipeline for this isn’t something I’m going to pursue. Thanks for the help.