Support for Arm Platforms (Pretty Please)

[tomtom215]

I was hoping to taking Habitat for a test drive after watching Kelsey Hightower's keynote at ChefCon.

When I went to run the bash install script, I started hitting some odd errors, which I traced down to me being a very edge case for support ---- I was attempting to run this on my Raspberry Pi 3b Kubernetes test cluster.

Now, I may sound like an edge case looking to run this project on a few $35 computers, but with institutions like Los Alamos National Laboratory running mini super clusters of Pi's, I think this may be a common use case for SYS admins and educational lab environments.

Thanks again for the awesome project!

[tashimi]

This is definitely an area of interest for the project, and we have a group of people who've done some work around it previously. cc @eeyun

Could you share what errors you were seeing?

[fnichol]

Yeah, would love to see any errors here. I know that doesn't get us a lot further into ARM support per se, but it would be good nonetheless. That install script is supposed to be more conservative bourne shell code meaning that /bin/sh, /bin/bash, /bin/ash, /bin/dash should ideally work.

[hdhoang]

One issue I have hit when building on ARM is nix 0.4 dependency in airlock (via unshare 0.1.15) and builder-graph (via copperline).

I have tried bumping to unshare 0.2.0 by running cargo update -p unshare --aggressive, and airlock still build fine. I suppose the breaking change for 0.2 series isn't used in airlock.

copperline master has upgraded to nix 0.5 for ARM support, but also broke compatibility majorly. I can see 2 ways forwards:

• patch the copperline's dependency: I haven't found out how to do so yet, will continue to investigate
• switch to another library: for example rustyline 1

[ehaselwanter]

would be awesome to be able to play with habitat on arm. is there any progress?

[raskchanky]

@ehaselwanter Sadly, no. At this point in time, this work isn't a priority. That doesn't mean it won't get done, just that it will likely be awhile before we're able to get to it.

[skull-squadron]

@raskchanky
Is the bigger problem is that the architecture is assumed everywhere, e.g., it needs: modifying the package format, passing it around in code, checking the build-time&runtime platforms, etc.?

[raskchanky]

@steakknife Everything you mentioned needs to get done, for sure. The biggest problem right now is too many things to do and not enough staff to do them.

[gscho]

Any updates on this issue? Seems to be increasingly relevant with the new arm based ec2 servers and chef 16 supporting arm.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We value your input and contribution. Please leave a comment if this issue still affects you.

[skull-squadron]

So is there focused, roadmapped, product-driven (not developer-driven) development on this or has it been largely abandoned?

[fnichol]

I'd be interested as well 😄 (currently not actively working on the project myself but ARM for servers and even Apple Silicon would certainly be a benefit these days)

[mwrock]

We are definitely revisiting this in earnest. There is some pending work that will be released in #8547 that will serve as a bridge (and for some possibly a destination) for this effort. That PR will allow you build packages for ARM and we will provide a linux-ARM64 habitat toolchain. These "native packages" are basically packages that are built outside of a studio and do not participate in habitat's dependency resolution. We will likely use it as a bootstrapping technique for building the required base plans of a particular ARM ecosystem. We are still discussing exactly which ARM flavor(s) this will include.

[skull-squadron]

The tasty ones. ;)

…

On Mon, Aug 22, 2022 at 8:37 AM Matt Wrock ***@***.***> wrote: We are definitely revisiting this in earnest. There is some pending work that will be released in #8547 <#8547> that will serve as a bridge (and for some possibly a destination) for this effort. That PR will allow you build packages for ARM and we will provide a linux-ARM64 habitat toolchain. These "native packages" are basically packages that are built outside of a studio and do not participate in habitat's dependency resolution. We will likely use it as a bootstrapping technique for building the required base plans of a particular ARM ecosystem. We are still discussing exactly which ARM flavor(s) this will include. — Reply to this email directly, view it on GitHub <#4151 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABWYMFPIDHZE5NRKRWMQTDV2N7CRANCNFSM4EFZT3OA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We value your input and contribution. Please leave a comment if this issue still affects you.