Add aarch64 support

[nilszeilon]

This will add support for installing Omarchy on aarch64 architecture and let you install on m-series macbooks!

Currently the m1 and m2 macbooks are supported by dual boot with asahi-alarm

[dhh]

I'm shocked how little change we actually need to support things! Love it.

[dhh]

Let's turn the install guide into a script ala source $OMARCHY_INSTALL/preflight/asahi.sh right after the guard or something. The fewer manual steps the better! Can use gum to ask for the inputs.

[keanehatescoding]

Arch Linux only officially supports the x86_64 instruction set. Will adding Arm support fundamentally make the project too complicated that it's better we just fork of this repo and add arm-omarchy specific features?

[jondkinney]

FYI, folks are currently able to one-shot their m1/m2 macs with my fork of nils fork. https://github.com/jondkinney/armarchy/tree/vm-testing

I'll be working with @nilszeilon on getting this merged in the near future. But it needs some cleanup.

Here are the instructions that have worked for people:

1. Install Asahi Alarm choosing "minimal".

    curl https://asahi-alarm.org/installer-bootstrap.sh | sh
   

2. Boot into Asahi-Alarm partition and login as the root user with the password you set

3. Configure wifi and update your pacman database, then reboot.

    iwctl station <station> connect <SSID>
    sudo pacman -Syu
    sudo reboot
   

4. Install wget

    sudo pacman -S wget
   

5. Install Omarchy from a custom fork and my vm-testing branch (which is, itself, a fork of nils fork)

    wget -qO- https://raw.githubusercontent.com/nilszeilon/armarchy/master/boot.sh | OMARCHY_REPO=jondkinney/armarchy OMARCHY_REF=vm-testing bash
   

This install script runs as root so it can create a user for you on your asahi-alarm partition, but then it switches to that user to run the "actual" omarchy installation. What that means is, if the installation fails, you'll want to re-run it locally by executing the local installer as your non-root user. The installer will auto-detect ARM architecture and set the correct flags. So if the install fails and you're still at a prompt that looks like it's logged in as root, figure out where it failed, and see if you have a local user you can login as instead to re-try the install.

~/.local/share/omarchy/install.sh 

I also have a guide in that branch for getting going with Parallels from scratch using ArchBoot which folks have been using successfully, too, on M3 and M4 macs (which can't work with Asahi-Alarm yet, if ever). https://github.com/jondkinney/armarchy/blob/vm-testing/full_install_guide.md

[dhh]

I would love to get everything boiled down to a single script that does it all.

[dhh]

We need to add a dedicated mirror added for https://archlinuxarm.org/ to deal with the aarch64 packages.

[jondkinney]

I would love to get everything boiled down to a single script that does it all.

@dhh are you saying you want to try to automate the asahi-alarm install as well? Or just once we get logged into linux on the m1/m2 a single omarchy install from there? If the latter, we have that right now with my vm-testing branch. If the former, we'd have to warp their setup script with the boot.sh and initiate that install. But we'd still have to execute the omarchy install again after it rebooted to the new partition, so I'm not sure it's beneficial to obscure what's happening there? But LMK what you're thinking for a flow to get asahi-alarm setup in the first place. Since it dual-boots, it's a bit different than being able to wipe out the whole drive and control everything, I think.

[DiedrikDM]

@jondkinney I was able to make my installation work on my M1 as well through your fork, thank you for the effort. For me an su to my local user was necessary and during installation I got an error message similar to vulkan/vulkan.h file not found. So for anyone concerned, you can then install the vulkan-headers package with sudo pacman -S vulkan-headers and restart the install script.

[abbood]

@jondkinney tried your solution, the asahi-alarm installer kept on choking on this part

Partitions in system disk (disk0):
  1: APFS [Macintosh HD] (994.66 GB, 6 volumes)
    OS: [B*] [Macintosh HD] macOS v15.6.1 [disk3s3s1, 3455A4F3-89E8-4656-BA92-94CA7F6F8EEC]
  2: APFS (System Recovery) (5.37 GB, 2 volumes)
    OS: [  ] recoveryOS v15.6.1 [Primary recoveryOS]

  [B ] = Booted OS, [R ] = Booted recovery, [? ] = Unknown
  [ *] = Default boot volume

Using OS 'Macintosh HD' (disk3s3s1) for machine authentication.

Choose what to do:
  r: Resize an existing partition to make space for a new OS
  q: Quit without doing anything
» Action (r): r


We're going to resize this partition:
  APFS [Macintosh HD] (994.66 GB, 6 volumes)
  Total size: 696.26 GB
  Free space: 330.13 GB
  Available space: 292.13 GB
  Overhead: 0 B
  Minimum new size: 404.13 GB (58.04%)

Enter the new size for your existing partition:
  You can enter a size such as '1GB', a fraction such as '50%',
  or the word 'min' for the smallest allowable size.

  Examples:
  30%  - 30% to macOS, 70% to the new OS
  80GB - 80GB to macOS, the rest to your new OS
  min  - Shrink macOS as much as (safely) possible

» New size (min): 80%

Resizing will free up 139.25 GB of space.

Note: your system may appear to freeze during the resize.
This is normal, just wait until the process completes.
» Continue? (y/N): y

Started APFS operation
Aligning shrink delta to 437,650,624,512 bytes and targeting a new container size of 557,011,959,808 bytes
Determined the minimum size for the APFS Container to be 372,672,299,008 bytes
Error: -69605: There is not enough free space in this APFS Container for this operation

Resize failed. This is usually caused by pre-existing APFS filesystem corruption.
Carefully read the diskutil logs above for more information about the cause.
This can usually be solved by doing a First Aid repair from Disk Utility in Recovery Mode.

I tried the following:

• I ran the first repair kit like 100 times on all my volumes, containers etc
• I cleared up my memory like crazy.. deleted all my obselete iOS and android emulators, app cache, i pretty much freed more than 200GB of junk on my 1TB HD, still not enough
• no matter values I put there to resize my HD, it kept on telling me that there is not enough free space.. which is total BS

It just didn't work for me.. I'll guess I'll just have to wait for Omarchy to be mac M1 friendly

[afansv]

@abbood This is an APFS problem that has long been known in the asahi community. A certain number of mac users encounter this. There's nothing asahi or omarchy can do about it.
See: https://www.reddit.com/r/AsahiLinux/comments/146alga/comment/jnq4m37/

[michapietsch]

I also have a guide in that branch for getting going with Parallels from scratch using ArchBoot which folks have been using successfully, too, on M3 and M4 macs (which can't work with Asahi-Alarm yet, if ever). https://github.com/jondkinney/armarchy/blob/vm-testing/full_install_guide.md

I just tested with VMware Fusion. I need to use /dev/nvme0n1 for the disk, and it seems to work fine at first.

But then I get the No volume contained a Limine configuration file error. I went through the troubleshooting.

Both files are there as expected:

-rwxr-xr-x 1 root root 229376 Sep 24 02:15 /boot/EFI/BOOT/BOOTAA64.EFI
-rwxr-xr-x 1 root root   1549 Sep 24 02:16 /boot/EFI/BOOT/limine.conf

Boot entry is this:
Boot0005* Limine HD(2,GPT,8b7c3241-2586-43c7-af7e-6c19eaaa5480,0x1800,0x100000)/\EFI\BOOT\BOOTAA64.EFI

Limine gets 0005 on my machine, and I adjusted the boot order and next boot settings accordingly.

@jondkinney, do you have any idea what else I could be missing?

[jondkinney]

@michapietsch check out #1897 for a more up to date branch that should be much easier to get fully installed, especially if you use the parallels image I reference in the PR description. It still includes all of the changes @nilszeilon made in this PR, by the way! Just more on top.

[devferrazZz]

@michapietsch It seems to be an issue with Fusion and Limine. I tried using VM Ware Fusion at first, since it's free and better alternative than UTM/QEMU. After hours of debugging I got this

LocateHandle for BLOCK_IO_PROTOCOL failed. Machine not supported by Limine UEFI.

That means the Limine EFI binary failed to access UEFI block devices on the VM. So the UEFI firmware inside VMware Fusion didn’t expose the Block I/O protocol in the way Limine expects, so Limine cannot enumerate/inspect volumes to locate/parse a limine.conf. So I guess that's something related on how Fusion supports UEFI.

So the alternative is to boot using GRUB, but I didn't try and went for @jondkinney's guide on my M1 MBP. Which I didn't have any problems, but the setup didn't finish successfully. After running the Omarchy install script I didn't get the final prompt confirming the user creation and other configs. My screen got pitch black and I had to force reboot.

Once the system restarted I got into Omarchy but I didn't have a login screen, it logged in directly. I wonder if I should run the installation script again by doing so

~/.local/share/omarchy/install.sh 

@jondkinney any thoughts ?

[balupton]

to clarify, will this support raspberry pi computers too, or just m-series macs? as all that has been discussed so far is asahi and macs...

[dinvlad]

@balupton aarch64 is a different CPU family/architecture from armv8 used on the Pis, so out of the box - no. Currently, Omarchy PR has flags targeting specifically the former. You would have to experiment by adding armv8 to the list and trying to get it to work. In all likelihood, many things won’t work out of the box because packages support remains scarce for ARM flavors. However, it seems ppl definitely got Arch Linux working on the Pis.

[petejkim]

Have you ever considered dropping Arch Linux entirely and switching to something like Debian with Nix, so that Omarchy could run on a broader range of systems? Nothing in Omarchy really requires Arch AFAICT.

[chardoncs]

I don't think Arch is the problem. In fact, Omarchy uses pacman to manage packages so it requires Arch

[drlucaa]

yes arch is the problem as its not officially supporting aarch64, but hyperland is only tested and guaranteed to work on arch and nixOS. So there isnt really another option than arch.

[petejkim]

nixOS has full support for aarch64

[balupton]

@drlucaa @petejkim arch supports it https://archlinuxarm.org/platforms/armv8/broadcom/raspberry-pi-4 (see the Installation tab) so you can stop spamming about other distros and pretending that arch doesn't

[petejkim]

@balupton Arch Linux ARM is an independent, unofficial project that is maintained separately from the official Arch Linux.

Also, see the following before you start putting 👎 emoji on every post, and be nice to others on the Internet.

https://www.reddit.com/r/archlinux/comments/1j1a01o/is_archarm_pretty_much_dead/

[balupton]

@petejkim thanks for providing that context, hadn't recognised they were seperate projects and that arch linux on arm is not only an abandoned project (effort could be revived) but also an abandoned effort (may not be worth reviving), now it makes sense why different distros were being discussed

[joske]

@nilszeilon @dhh I'd like to add an omarchy variant for asahi-alarm as there seems to be enough interest. However, the scripts as they are now are interactive and I'm hitting many roadblocks (our installer build runs as root). Would there be a possibility of an unattended script/option?

Also, our installer would already create a sudo user, install the required asahi packages etc

[jondkinney]

@joske I've been working with @ryanrhughes on this effort, and this is the PR that will be ultimately be merged in #1897 so let's move the conversation over there.

[ryanrhughes]

Closing in favor of #1897. We should continue to clean that up and whittle it down to only the required elements but it's the closest to 1-1 addition of aarch64 support at the moment.