Skip to content

Architecture Support

Jump to bottom
Daniel Massey edited this page Jun 22, 2026 · 4 revisions

Architecture Support

This article lists the CPU architectures supported by MassOS, and any notes or caveats related to them.

Architectures

x86_64

This architecture may sometimes be referred to as x64, AMD64 or EM64T.

  • Fully supported and has the best compatibility for running MassOS.
  • Legacy BIOS and UEFI are both supported boot methods.
  • Every build and/or release of MassOS will be provided for x86_64.

All x86_64 builds can be downloaded from here.

aarch64

This architecture may sometimes be referred to as ARM64 or ARMv8.

  • Limited support and compatibility. There is ongoing development work to (gradually) improve support and (hopefully) eventually reach parity with x86_64.
  • UEFI is the only supported boot method. Custom/proprietary booting mechanisms common on aarch64 platforms (for example: Raspberry Pi) are currently unsupported.
  • Devices relying on OS-provided Device Tree Blobs (DTBs) are not (yet) (fully) supported, however development work is ongoing to support them. As of June 2026, DTBs from the Linux kernel are installed under /boot/dtbs (or /dtbs on the Live CD), and can be manually loaded at boot time by using GRUB's devicetree command (after the normal invocation of the linux and initrd commands). The DTB loading process is not yet automated - more work needs to be done regarding this.
  • Raspberry Pi devices may or may not be able to boot using (e.g.) the unofficial UEFI firmware. A script eventually needs to be developed, which produces a MassOS SD card image, by making use of the Raspberry Pi's internal boot mechanism. It should be called create-raspi.sh, and can be considered analogous to already existing create-livecd.sh script. This is currently WIP.
  • Support for Windows-on-ARM (WoA) devices, such as Qualcomm Snapdragon X series laptops, is still WIP, but most development focus at the time of writing is on making this work. These machines require DTBs as described above, as well as some custom kernel parameters. To get audio working, non-Lenovo systems also currently require manually dumping firmware from a (dual-booted) Windows installation using the qcom-firmware-extract program. This article will be updated with more details about this once additional work and testing has been done by the MassOS developers.
  • Currently there are no regularly-provided aarch64 builds of MassOS. This is primarily due to the MassOS maintainers lacking ownership of suitably powerful hardware for compiling aarch64 builds. You're free to try Building MassOS yourself if you do own such hardware and are up for the task!

Only a few official aarch64 builds have thus far been produced by the MassOS developers. You can download them from here, if you (for example) wish to use it as a base system for your own builds. Contributions are welcome!

32-bit Compatibility

32-bit CPU Support

MassOS has no support for running on CPUs with legacy 32-bit architectures, and no such support is planned. Aside from unnecessary maintainence work required for aging and largely obsolete hardware, 32-bit CPUs cannot address more than 4GB of system RAM, which is often insufficient for modern programs, especially demanding ones.

32-bit Program Compatibility

Most 64-bit architectures, including x86_64 and aarch64, have CPU-inbuilt backwards compatibility, which allows them to run 32-bit binary programs and machine code. An OS which provides support for running 32-bit applications alongside native 64-bit ones, is referred to as a "multilib" system.

MassOS does NOT provide any 32-bit support libraries which are required for running dynamically-linked 32-bit programs under a 64-bit host system. This is partly due to the disk space cost - a large portion of the native (64-bit) system libraries that are present on the MassOS system, would have to essentially be duplicated, for multilib support - they'd need to be compiled by the MassOS developers twice (once for the native 64-bit version and once for the backwards compatible 32-bit version), and both of those copies of each library would have to be installed on the system. As such, the MassOS developers have made the decision to not include multilib support on the MassOS system.

Nonetheless, there are still options available for running 32-bit applications, if you want or need to do so. These are as follows:

  • Look for a native 64-bit version of the program you are trying to run. If it's a precompiled binary package, the same download page should have an option for 64-bit systems. If it doesn't, and the program is free software, then you may be able to compile it yourself for 64-bit, following the building instructions in the project's documentation (often in the source tree).
  • Look for a Musl-based fully-statically-linked copy of the program. Musl is an alternative C library to Glibc, with the main advantage of being able to be fully statically linked into programs. This means the program will have NO runtime library dependencies on the host system at all. In this case, if the application is 32-bit, it can run on the 64-bit MassOS host system, because the system itself supports running 32-bit code, it's just that, as described above, the multilib libraries normally required for running 32-bit applications are not included on the MassOS system.
  • See if your application is distributed through the Flatpak package manager, which is included on MassOS, and has native 32-bit compatibility support, using it's own libraries that are independent of the MassOS system libraries. For example, if you install an application requiring multilib support from Flatpak, such as Bottles, it will have multilib support by default.

Clone this wiki locally