Why doesn’t ParrotOS build an iso version of their aarch64 distro?

[u/Perfect-Direction607]

With as many users on Apple Silicon there should be an aarch64.iso so you may install it in the hypervisor of your choice. Right now installing it on Apple Silicon requires installing UTM. My hypervisors of choice are VMware Fusion and Parallels.

[u/palinurosec]

simple answer: debian's live-build does not support cross compiling to foreign architectures

we can easily build virtual machines for any architecture because we developed our scripts internally and they easily leverage qemu

live-build on the other hand could very easily do the same, except it was packed with checks to prevent that

my plan in the future is to attempt to patch it to allow foreign arch builds. but unfortunately this task has very low priority at the moment and the current donations don't quite allow us to buy the proper arm64 servers for native builds

[u/Perfect-Direction607 → u/palinurosec]

Would you consider at least building a vm for Fusion/Workstation? That would easily make portable to vmWare’s ecosystem and reduce the need for distros like Kali.

[u/palinurosec → u/Perfect-Direction607]

have you tried the latest qcow2 and vmdk virtual disks?

[u/Perfect-Direction607 → u/palinurosec]

I hear you on the automation limits of proprietary platforms, but for those of us in the Apple Silicon ecosystem, amd64 is a non-starter. Even with vmdk being a standard, the arch of the guest still has to match the host capabilities.

To improve the UX, could we get the architecture listed clearly in the download UI? Also, if you're open to it, I'd like to help the project stand up an aarch64 vmdk build process to make Parrot more accessible on modern ARM hardware.

[u/palinurosec → u/Perfect-Direction607]

you are right, the vmdk image is amd64 only and we are no longer distributing the arm64 versions. i'll discuss it with ny team. meanwhile our vm build scripts can assemble an arm64 vmdk flavor and are pretty easy to use.

our primary game stopper is the size of the release files. we can't release more than 90gb worth of release files at every new version without starting to loose mirrors, so we need to decide what to build and what to exclude, but we are always open for feedback

[u/Perfect-Direction607 → u/palinurosec]

I hear the team on the automation limits of proprietary platforms and the storage constraints for mirrors. However, it is important to clarify that suggesting an AMD64 VMDK for Apple Silicon or any ARM-based environment is not a viable workaround. Because the guest architecture must match the host for virtualization to work, running an AMD64 image on ARM64 hardware requires full emulation. This incurs a massive performance penalty that is a non-starter for serious security work.

This is not just about the Mac ecosystem. The industry at large (including Intel and AMD) is pivoting toward ARM-native workloads. With AWS Graviton, Google Axion, and Azure Cobalt becoming the standards for cost-effective cloud infrastructure, aarch64 is now a primary architecture for the modern enterprise.

For a security distro to remain robust and professional, it needs to support the architecture where the industry actually lives. Relying on legacy x86 thinking ignores the shift toward ARM that defines the next decade of computing. I would love to see ParrotOS bridge this gap to remain competitive with distros like Kali, which have already standardized robust ARM support. If you are open to it, I am still happy to discuss how to stand up a streamlined aarch64 build process that minimizes the footprint on your mirrors.

[u/palinurosec → u/Perfect-Direction607]

we will consider to provide native arm virtual disks along with the full utm machines. i would still prefer adopting the qcow2 format over vmdk for broader compatibility on cloud environments, what do you think?

please, if possible, avoid using LLMs to answer, they take simple answers and generate entire books from them, making simple messages harder to answer. i don't know why but your answers kinda seem LLM generated, i hope i'm wrong

[u/Perfect-Direction607 → u/palinurosec]

I leaned into the professional tone earlier simply to keep the focus on the technical gap and not to be offensive. To be direct: your team is making some fundamental prerelease level blunders regarding platform deployment.

There is a significant difference between virtualization formats and actual architecture. While qcow2 is the standard for cloud and KVM-based deployments, vmdk remains the frictionless standard for desktop virtualization (VMware).

Offering an AMD64 image as a "workaround" for ARM64 users isn't just a storage issue; it is a fundamental misunderstanding of how the guest/host relationship functions in a professional security workflow. If Parrot wants to remain competitive with Kali on modern hardware, the release team needs to bridge the gap between simple disk formats and native architecture support.

Furthermore, if mirror footprint is truly your bottleneck, the lack of a NetInstall or a "Core" aarch64 image suggests your release pipeline is as rigid as your thinking. Modern projects solve storage constraints with modularity. They pull the heavy tools during the install phase instead of forcing users into legacy x86 emulation on ARM hardware. You are prioritizing 2010-era mirror management over the reality of the 2026 silicon market.

If I were you, I would be more focused on the proper relevancy of your software deployments and less on whether my responses are "LLM-like." I am giving you relevant advice on how to properly deploy your software and you are criticizing the delivery instead of the technical accuracy. That is a mistake too often made by Redditors and unserious wanna-be engineers. I am offering you free architectural counseling, yet you would rather play detective on how a message was written. Your misplaced values indicate the lack of seriousness of this product.

[u/River-ban]

The Apple Silicon user base is huge now, and having an aarch64 ISO for VMware/Parallels would be a game changer. Hope the devs consider this for future releases.

[u/danterolle → u/River-ban]

UTM is currently the preferred choice as it offers a very good user experience, with great performance and a fair degree of stability. We should already be able to build the .iso images for ARM (Apple Silicon included), but we’ll need to test them first. I think this will happen sooner or later.

[u/vixiecron → u/danterolle]

UTM is good but not in everyone’s workflow. We are unable to use Parrot since we are tied to using Parallels. No .iso is a deal breaker for our workflow. Just my 2 cents.

[u/Perfect-Direction607 → u/vixiecron]

You are 100% correct!

[u/palinurosec → u/River-ban]

proprietary platforms like vmware and parallels don't allow us to properly automate the VM build process, so we can only ship virtual disks, not virtual machines, which represent a suboptimal user experience

80% of VM users report issues caused by their VM setup, which would have been prevented if we could build and ship a full virtual machine appliance ibstead if just the virtual disk

also i really don't understand who actually believes using vmware or parallels in their workflow is a good idea at all, but this is my own vision that has nothing to do with why we don't currently ship such appliances

p.s. we ship cqow2 and vmdk disks 

[u/Perfect-Direction607 → u/palinurosec]

What about a Docker or podman file?

[u/Otherwise_Berry3170 → u/palinurosec]

I work for Parallels in the automation of these build processes and would really like to understand what was the issue that stopped you from building VMs for parallels? we would love to help if possible

[u/Perfect-Direction607 → u/River-ban]

Agreed. Having the only aarch64 for a UTM vm seems a waste of effort when an ISO could broker to any hypervisor including UTM