Hey all, I’ve been following the “get started” pro...
# getting-started
Hey all, I’ve been following the “get started” project but ran into a snag when I tried to run “pulumi up”
Copy code
Type                 Name            Plan       Info
 +   pulumi:pulumi:Stack  quickstart-dev  create     2 messages
  pulumi:pulumi:Stack (quickstart-dev):
    assertion failed [arm_interval().contains(address)]: code fragment does not contain the given arm address
    (CodeFragmentMetadata.cpp:48 instruction_extents_for_arm_address)
Any clues what could be going on?
I am also facing this
Which getting started project are you using @billowy-country-88419?
@lemon-scooter-94063 I am using the Starter project, AWS with Python
Got it, I was hoping to recreate on my end but that starter just creates an S3 bucket so you must have added more code. Without more context hard to say what the cause might be. I'd try to output the values you are using in
to make sure the values are what you're expecting.
I don’t believe I’ve added any new code, maybe Ill try starting over and see if that helps
I ran through it on my mac and didn't run into any issues
We are developing a golang base CLI to create AWS DocumentDB clusters and everything works great for me on macOS 14.5 (Apple M1) but since the sdk update to version
, some buddies are having this issue:
Copy code
pulumi:pulumi:Stack jarvis-molivas running assertion failed [arm_interval().contains(address)]: code fragment does not contain the given arm address
  pulumi:pulumi:Stack jarvis-molivas running (CodeFragmentMetadata.cpp:48 instruction_extents_for_arm_address)
also present here:
Hmm the latest version of Go seems to be 3.122 so upgrading first to that version might provide a solution to this error
I’m seeing this as well using aws-typescript. I’m trying to spin up a simple fargate cluster but
pulumi up
hangs indefinitely with this same error. Very frustrating as I’m trying to do a proof of concept but the feedback loop with Pulumi is slowing me down. I’ve upgraded pulumi CLI but didn’t help
It looks to me like the issue is in pulumi-aws 6.42.0 - I downgraded to 6.41.0 and I no longer see this issue when running pulumi up
Same problem for our pulumi projects for preview/up. Downgrading to 6.41.0 fixed it.
(Incidentally, the third time in the last 6 months we've had to downgrade/pin a version after seeing preview/up hang after a release ... 😕)
Hey, I did some digging and found that
relates to Rosetta2 on macos. Could it be that you're running an x86_64 pulumi binary on an apple silicon Mac? Can you send the output of
pulumi about
Copy code
> pulumi about                                                                                                                 
Version      3.122.0
Go Version   go1.22.4
Go Compiler  gc

language  nodejs  unknown

OS       darwin
Version  14.5
Arch     arm64

This project is written in nodejs: executable='[redacted]/.nvm/versions/node/v18.20.1/bin/node' version='v18.20.1'

Current Stack: [redacted]

TYPE                 URN
pulumi:pulumi:Stack  [redacted]

Found no pending operations associated with [redacted]

Name           [redacted]
URL            s3://[redacted]
User           [redacted]
That's interesting, I'd have expected that it shows a different architecture. Do you mind running the following command to show the architecture of the aws provider to confirm whether it's related to binary translation?
Copy code
file ~/.pulumi/plugins/resource-aws-v6.42.0/pulumi-resource-aws
In the meantime I opened a GitHub issue to capture this problem: https://github.com/pulumi/pulumi-aws/issues/4190 So sorry that y'all are running into this!
Copy code
~/.pulumi/plugins/resource-aws-v6.40.0/pulumi-resource-aws: Mach-O 64-bit executable x86_64
~/.pulumi/plugins/resource-aws-v6.41.0/pulumi-resource-aws: Mach-O 64-bit executable x86_64
~/.pulumi/plugins/resource-aws-v6.42.1/pulumi-resource-aws: Mach-O 64-bit executable x86_64
~/.pulumi/plugins/resource-aws-v6.43.0/pulumi-resource-aws: Mach-O 64-bit executable x86_64
Interesting, given that I'm on an M1 Mac. But still seems to work with 6.41.0. Thanks for getting into it.
And what's the output of
file "$(which pulumi)"
? I wanna check whether the pulumi CLI itself is an
binary as well
/opt/homebrew/bin/pulumi: Mach-O 64-bit executable arm64
Do you mind removing the AWS provider (
pulumi plugin rm resource aws 6.42.0
), then re-install it (
pulumi plugin install resource aws 6.42.0
) and check it's architecture again? And please also check the architecture of your node binary. It seems to be in
Removing 6.42.1 and 6.43.0 and installing with the CLI as indicated switches the arch from x86_64 to arm64. Node binary is arm64.
Just to confirm, the
based AWS provider works as expected and doesn't run into the same issue as the
one? How did you install providers previously? Automatically when running a Pulumi Program or are you using automation API (or some tool that wraps it)? I'm trying to understand how/why an x86_64 provider got installed. Could you remove the provider again and run your usual Pulumi workflow with increased log level (add
to the CLI command) and inspect the architecture of the downloaded provider binary. Thanks!
I was personally using homebrew,
brew install pulumi/tap/pulumi
@billowy-country-88419 can you check the architecture of your pulumi binary please?
file "$(which pulumi)"
/usr/local/bin/pulumi: Mach-O 64-bit executable x86_64
Also saw this in pulumi about. I’m using an M1 Macbook
@billowy-country-88419 You've seem to have installed an x86_64 binary of pulumi. Can you try using the native arm64 one. Are you're running homebrew in x86_64 mode?
I don’t believe I am running homebrew in x86_64 mode, how would I check?
You can run
to check the architecture for the current shell session. Brew will use that for installing packages. If it comes back as arm64 you can try uninstalling pulumi and re-installing it again with
arch -arm64 brew ...
to force it to use the right architecture.
Tried to do an reinstall the same method as before and it didn’t work, adding arch -arm64 also did not work. Going to just do a manual download from the site https://www.pulumi.com/docs/install/
Yes that way you should definitely get the correct architecture! What's the output of
brew config
for you? That might give a hint why it installs x86 packages for you
Copy code
ORIGIN: <https://github.com/Homebrew/brew>
HEAD: e5f776b3e23cae8f1b6c3d1194b8329bf701965f
Last commit: 7 days ago
Core tap HEAD: 47afb81ec90726250b64a104d5a7b72cf9a360f6
Core tap last commit: 5 days ago
Core tap JSON: 07 Jul 21:16 UTC
Core cask tap JSON: 07 Jul 21:16 UTC
HOMEBREW_REPOSITORY: /usr/local/Homebrew
HOMEBREW_CELLAR: /usr/local/Cellar
HOMEBREW_DISPLAY: /private/tmp/com.apple.launchd.HiMMQyiyxF/org.macosforge.xquartz:0
Homebrew Ruby: 3.3.3 => /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/3.3.3/bin/ruby
CPU: octa-core 64-bit westmere
Clang: 15.0.0 build 1500
Git: 2.29.2 => /usr/local/bin/git
Curl: 8.6.0 => /usr/bin/curl
macOS: 14.5-x86_64
Xcode: N/A
Rosetta 2: true
I think that’s found the reason! not sure how to fix that but thanks for the help
Nice! Ideally also remove the cached Pulumi Plugins so they get re-installed with the correct architecture.
Yep, ran
rm -rf ~/.pulumi
which should get everything.
Thanks Florian, this was exactly my problem as well, x86_64 architecture on an M1 Mac with Homebrew setup for x86_64 . @billowy-country-88419 I’m reinstalling Brew to make sure it gets the ARM version of Pulumi. Found this thread with some steps on how to do that if you’re interested -> https://github.com/orgs/Homebrew/discussions/545#discussioncomment-540891
Confirm that i can now run pulumi up on aws 6.42.0. I still needed to run
pulumi plugin rm resource aws 6.42.0
even after uninstalling and installing pulumi, but it’s all working now. Thanks again @quick-house-41860
For me, everything is arm except for the pulumi-resource-aws files. Confirmed that the issue is resolved when those are using the correct arch. My flow is using yarn (via turborepo) to update
, then running pulumi commands as usual. After deleting 6.43.0, I couldn't replicate the problem;
pulumi preview
correctly downloaded the arm version of 6.43.0. Wondering if maybe a different pulumi flow is the problem:
pulumi refresh
, or the automation API, or something like that. I'll keep an eye out.