Support fleetctl for linux arm64 so that you can build fleetd packages on linux arm64

[nonpunctual]

Fleet version: <!-- Copy this from the "My account" page in the Fleet UI, or run fleetctl --version --> 4.49.0 Web browser and operating system: macOS 14.4.1 Apple M2 Pro - Apple Silicon arm64

---

💥  Actual behavior

I would like to be able to run Ubuntu vms in tart on my Fleet production Mac & enroll them as hosts in Fleet for testing. Apparently, I can't.

🧑‍💻  Steps to reproduce

I installed npm & installed fleetctl & got the following:

I rebuilt the vm & I downloaded the fleetctl binary from the github page. Same result.

🕯️ More info (optional)

@edwardsb believes what I am seeing is the result of the fleetctl binary not being complied for arm64. I realize that makes this potentially a FR & not a bug, but, it is a bug if our customers are attempting to use linux vms on Apple SIlicon Macs & we don't warn them that this is not possible. This could be closed if the issue linked below (which I was helpfully reminded of by Roberto) was resolved.

https://en.wikipedia.org/wiki/Apple_silicon

The first Macs built with the Apple M1 chip were unveiled on November 10, 2020. As of June 2023, the entire Mac lineup uses Apple silicon chips.

Please compile the fleetctl binary & the fleet binary for arm64 & make them available through normal distribution. Thanks.

[nonpunctual]

Addendum:

Apparently, even with Parallels running an x86 emulation Ubuntu vm (i.e., in Parallels there is an option for running a vm in Docker that is supposed to use Rosetta) the fleetctl binary is failing some architecture check & will not run in a vm hosted on Apple Silicon. This in my opinion is an actual bug unless I don't understand what's happening.

None of this makes much sense. Maybe the x86 emulation only is a thing in the Ubuntu Desktop env.

[lucasmrod]

Hi folks! My 2cents:

There seems to be two separate requests here: (1) Support fleetctl for linux arm64 so that you can build fleetd packages on linux arm64. (2) Fleet to offer fleetd components (orbit and Fleet Desktop) for linux arm64 in its TUF (and leverage the existing osquery for linux arm64 in https://osquery.io/downloads/official/5.12.1). When you execute fleetctl package it downloads fleetd components from Fleet's TUF server (and it currently doesn't host linux arm64 executables).

Maybe this issue can be converted to fix request (1). And #1845 exists for request (2).

[lukeheath]

@nonpunctual I don't think this is a bug unless, unless we claim to support tart and don't. If not, please re-spec as feature request (or could be engineering-initiated if it's purely for local testing).

[nonpunctual]

@lukeheath I agree with you about the original report & I can separate these issues, but, in my comment I hope it's clear that my Ubuntu vm is an x86 emulation using Rosetta. To me, that means that fleetctl should open on that VM.

It is fairly common even on native macOS is that architecture checks using binaries like arch see aarch64 somewhere & then ignore the fact that x86 emulation is being used. That seems like a bug to me.

[lukeheath]

@nonpunctual Yes, please separate the feature request part from the bug. Is this the request?

Please compile the fleetctl binary & the fleet binary for arm64 & make them available through normal distribution.

As for the bug:

I realize that makes this potentially an FR & not a bug, but it is a bug if our customers are attemptininux vms on Apple SIlicon Macs & we don't warn them that this is not possible.

Are any customers trying to use Linux VMs on Apple Silicon Macs? We don't consider VMs running on different hardware as part of our compatibility. For that reason, I suggest this bug be closed and a single feature request is opened. If I need clarification on something and there is a bug in how Fleet is documented to work, please revise and let me know. Thanks!

[nonpunctual]

Hi @lukeheath

Thanks, I have converted this to a FR. I will make a separate bug report for the x86 emulation problem.

• Apple Silicon has been out since 2020
• With the Mac Pro tower as the single exception, Apple no longer makes Intel Macs.
• We market ourselves as a "Mac first" MDM.
• I am trying to use Linux VMs on Apple Silicon Macs.
• Can't we assume that customers would want this capability?
• How many customer reports of trying to run a vm on the only Macs Apple makes would be sufficient?

I am a little baffled by the idea that we would not support this. This is, as I see it, another example of "dogfood" perhaps causing internal biases to prevent us from seeing the outside world as it is.

[lukeheath]

@nonpunctual It's not so much a question of do we want to support this, but do we claim to support it? If so, then not supporting it is a bug. If not, then supporting it is a feature request.

[noahtalerman]

@nonpunctual heads up, I updated the title of this feature request to the following: Support fleetctl for linux arm64 so that you can build fleetd packages on linux arm64

Let me know if that's not right.

[nonpunctual]

It was originally a bug report so totally fine.

[noahtalerman]

Closed because it's a duplicate of this issue:

• 1845

[fleet-release]

Fleetctl on arm64, Security tests in the clouds, Harmony restored.

[nonpunctual]

Are any customers trying to use Linux VMs on Apple Silicon Macs?

@noahtalerman @lukeheath

https://github.com/fleetdm/fleet/issues/1845#issuecomment-2106039735

[lukeheath]

So I actually ran into a use case of needing this. I need to run the fleetctl binary in linux in a VM on an arm64 mac. This was closed as a duplicate, but the other ticket ended up getting descoped to only include the fleetd agent and not the fleetctl binary itself. Re-opening so that we can track the need for an ARM64 fleetctl binary.

[lucasmrod]

If somebody is blocked by this (until this gets added in the goreleaser workflow):

CGO_ENABLED=0 GOOS=linux GOARCH=arm64 go build -o ./build/linux/fleetctl-arm64 ./cmd/fleetctl

file ./build/linux/fleetctl-arm64
./build/linux/fleetctl-arm64: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, Go BuildID=pciHUdQKK7rNO2tWWo3K/UqQ6DqfTpFEBXO37xe28/4ylWj10NvsVA1nZZVCvN/GIVNZPC8bk5erzFZ0pnH, with debug_info, not stripped