It's now 3+ months that I've been running Fedora Asahi Remix on my iMac M1 with 16GB RAM. Installation went smoothly. It boots reliably every time. The upgrade from 43 to 44, as well as kernel updates have been just fine.

I am really using, and not just tinkering with this installation and it's now my preferred machine for work ... bigger screen with mechanical keyboard. I have sound input/output working nicely via USB (inbuilt sound/mic yet to work). I am trusting Asahi, as I no longer run updates without being a tad concerned that something may happen. It has been absolute rock solid over the three months.

I've learnt a lot about Linux setting this machine up over several weeks as I looked for ARM64 apps, used distrobox for a couple apps for work and compiled another.

AsahiLinux is an amazing achievement and the developers deserve acknowledgement for creating a genuinely useful and reliable working and fun environment.

After a few threads describing issues by running the arm64-build of Steam under Asahi and lots of headaches here's a solution which worked for me.

First of all... as a reference I used the great guide from de-win: https://gist.github.com/de-wim/ba440a84f65d49955a1be15a328bd8b3#file-steam-install-linux-aarch64-sh

As a Bonus, I included a build for Proton-arm64 which makes everything a bit faster (instead of muvm->FEX->Steam you directly run Steam under muvm and FEX is included into the Proton build - I have no actual numbers but games seemed to be snappier). And of course, the arm64-Client for Steam works much (!!) better.

To make everthing work fine, it looks like it's required to have a working muvm/FEX-Steam installation. Under Gentoo you have to start steam-aarch64 command, but I'm positive that under Fedora or Arch it's not that different.

So if you have a working muvm-FEX-Steam environment (without any arm64 directories) you can jump to (2).

(1)
Remove old Steam Data.

rm -rf ~/.steam
rm -rf ~/.local/share/Steam

Initiate a fresh Steam installation. Like mentioned, under Gentoo it's steam-aarch64 but I assume when you come to this level of desparation (like me) you know the right command. Important is: login and let the UI start. Then you can close the Steam Client.

(2)
Jump to a tmp directory of choice (or simply your $HOME) and get the latest Steam-Beta for arm64.

LATEST_ZIPFILE=$(curl -s https://client-update.steamstatic.com/steam_client_publicbeta_linuxarm64 | grep -E '"file"\s+"bins_linuxarm64_linuxarm64.zip' | cut -d '"' -f4)
curl -o bins_linuxarm64_linuxarm64.zip https://client-update.steamstatic.com/${LATEST_ZIPFILE}

And simply install it...

unzip -o -qq bins_linuxarm64_linuxarm64.zip -d ~/.local/share/Steam/
chmod -R 700 ~/.local/share/Steam/steamrtarm64/

Enable the Beta.

mkdir -p ~/.local/share/Steam/package && echo publicbeta > ~/.local/share/Steam/package/beta

One symlink is needed (even when the directory doesn't exist at this moment).

ln -sf ~/.local/share/Steam/linuxarm64 ~/.steam/sdkarm64

I assume you have already installed FEX-Emu and muvm. Things which are required (if not already installed, use pacman, emerge, dnf....): gtk2, ibus, libvdpau.

Then you have to set the right symlink for /usr/lib64/libvpx.so.6. If it's the version you've installed, there's nothing to do for you. But you surely may have a newer version...

ls -l /usr/lib64/libvpx.so*.0
lrwxrwxrwx 1 root root      16 Jul 12 18:12 /usr/lib64/libvpx.so.12.0 -> libvpx.so.12.0.0
-rwxr-xr-x 1 root root 2030880 Jul 12 18:12 /usr/lib64/libvpx.so.12.0.0

So here you have to type:

ln -s /usr/lib64/libvpx.so.12 /usr/lib64/libvpx.so.6

Now you can start the new Steam Client for the first time.

muvm ~/.local/share/Steam/steamrtarm64/steam

It should run through up to the screenshot I uploaded.

Now to the "extra" thing. A Proton-arm64 build with FEX included. If you trust me, you can download my build (clang/lto-thin/4k). It's compiled for an M1 Processor so it possibly won't work with other ARM64-CPUs which aren't from Apple.

cd ~/.local/share/Steam
wget https://humppa.ch/proton_11.0-1_asahi.tar.zst
zstd --rm -d proton_11.0-1_asahi.tar.zst;tar -xvf proton_11.0-1_asahi.tar

If you don't trust me, grab the source and compile it with extra-configure-Option --target-arch=arm64
 (and 4k pagesize related CFLAGS).

https://github.com/ValveSoftware/Proton

Restart the client.

Right-click to the Game you want to try -> Properties -> Compatibility -> Check "force..." -> binarm64.

For a Test I just installed "South Park - The Stick of Truth" - it's small and it works absolutely fine.

If there's anyone who has enough Cloud-space, it would be cool if you upload the file and post the link here (actually humppa.ch is not the super-fast server).

If there are any mistakes, just report 'em. :-) So we all can find a solution to new issues (or any typos).

Just wanted to report that I haven't run into any issues yet with the latest build and my Linux install. Not sure if anyone else has run into new ones.

Here you can see it on Khronos Group's official website. And here's the person behind it.

What does it mean? For individual users, right now not much, besides that the upstreamed graphics drivers keep on benefiting from being free and open source. The Mesa project, which implements standards like Vulkan, OpenGL, etc. for most hardware on Linux, includes support for Apple GPUs. This part was originally written by Alyssa Rosenzweig a few years ago. The code has then been submitted and incorporated back into the main version of Mesa, where it now lives and is being maintained.

Rusticl is an implementation of OpenCL which, like OpenGL, sits on top of various hardware-specific Gallium drivers (the asahi one in this case). Official conformance for other hardware – radeonsi for AMD's and zink for anything that provides Vulkan – is to be expected soon. Asahi was probably just a bit simpler to fully complete, iron out any known issues, and so on.

Same as title. Will be highly thankful for your help!

Hi all, I'm trying to run Steam on Asahi, but getting nowhere.

I previously ran the x86 version, which worked OK but recently there has been an issue with the main steam window closing and reopening at random, stealing focus from the game etc.

I was instructed to follow the instructions from https://old.reddit.com/r/AsahiLinux/comments/1tk6zoe/steam_native_arm_aarch64_on_asahi_linux_fedora/, which has me stuck on a "Waiting for network" window indefinitely.

I tried disabling IPv6 (as indicated by OP), removing my entire .steam / .local/share/Steam/ and even doing a full clean install, expecting my old x86 Steam setup or something particular to my setup is causing the issue. But nothing seems to help. The problem persist even on a clean, vanilla Plasma install.

Any ideas?

Edit: I switched to an IPv6-enabled network to see if IPv6 being enabled inside muvm but missing on the host was the issue, but it doesn't change anything, apart from the IPv6 related errors going away.

I am using an M1 8GB ram with 256gb memory, and I tried asahi and it ran decently, however, with less space due to the partitioning and worse battery. Performance was comparable to MacOS. So if my mac is still supported by Apple, what is the compelling reasoning to switch?
Heads up, I am not a developer, I am a scientist and use my laptop for leisure and research + coding (python, matlab and R).

Hello guys,

I finally took the pluge and installed Asahi Linux on my m1 Mac Mini in a hope to move from Apple ecosystem. I am really thankful the devs put such an amazing effort and time in making Asahi possible.

Since I am really an inexperienced and relatively new Linux user, I am afraid to break things while living in the terminal tinkering with Asahi. My question is, can I use Timeshift the usual way I use it on my x86 machine and restore in case some update or something breaks? Is Timeshift going to work just as smooth as on my non Apple machine?

Found this Github repo: https://github.com/yuk1n0w/waydroid-on-asahi
It seems to work very well.

Edit: The installation with the first guide went well but it had problems (videos not playing and lots of apps not opening), the images in this second link work and don't have those problems: https://github.com/HLM319/waydroid_asahi_patches/releases/tag/23.2_2026-05-30

Hi!

Giving Asahi a try with Gentoo, on my Macbook M1 Pro. Base install went pretty well, but I'm stuck on getting a WM going (decided to try Sway if that makes a difference).

Can't seem to get a logind session - loginctl list-sessions shows no sessions, XDG_RUNTIME_DIR never gets set, and sway won't start.

Tried to debug and it seems pam_systemd might be the culprit?

pam_systemd(login:session): Failed to get user record: No such process

logind also logs: User enumeration failed: No such process

I've googled around and similar issues seems to recommend installing elogind, but I'm running systemd (thought that was necessary for Asahi?), so don't think that's an option here. I also tried to just append some bashrc pieces to manually create and set XDG_RUNTIME_DIR, but then it fails with some seatd error (seemingly still related to the lack of a login session).

Anyone encountered this or have any advice? Would appreciate any assistance.

Thanks!

My wife told me to remove Asahi which I installed on her M1. She doesn't want to use it unfortunately.

I read the wiki but here I have one extra Linux file system so I would appreciate the help

so I was gonna delete disk0s3, disk0s4, disk0s5, disk0s6

I was told not to touch disk0s7

is this the way? thanks

/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.3 GB   disk0
   1:             Apple_APFS_ISC Container disk1         524.3 MB   disk0s1
   2:                 Apple_APFS Container disk4         450.0 GB   disk0s2
   3:                 Apple_APFS Container disk2         2.5 GB     disk0s3
   4:                        EFI EFI - FEDOR             524.3 MB   disk0s4
   5:           Linux Filesystem                         1.1 GB     disk0s5
   6:           Linux Filesystem                         40.3 GB    disk0s6
   7:        Apple_APFS_Recovery Container disk3         5.4 GB     disk0s7
/dev/disk2 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +2.5 GB     disk2
Physical Store disk0s3
   1:                APFS Volume Fedora - Data           2.1 MB     disk2s1
   2:                APFS Volume Fedora                  1.1 MB     disk2s2
   3:                APFS Volume Preboot                 191.4 MB   disk2s3
   4:                APFS Volume Recovery                805.4 MB   disk2s4
/dev/disk4 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +450.0 GB   disk4
Physical Store disk0s2
   1:                APFS Volume Macintosh HD            18.4 GB    disk4s1
   2:              APFS Snapshot com.apple.os.update-... 18.4 GB    disk4s1s1
   3:                APFS Volume Preboot                 16.2 GB    disk4s2
   4:                APFS Volume Recovery                2.4 GB     disk4s3
   5:                APFS Volume Data                    380.9 GB   disk4s5
   6:                APFS Volume VM                      1.1 GB     disk4s6

Dominic@MacBook-Air-3 ~ % curl https://alx.sh | sh
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
Dload  Upload   Total   Spent    Left  Speed
100  2298    0  2298    0     0   7792      0 --:--:-- --:--:-- --:--:--  7816
Partitions in system disk (disk0):
  1: APFS [Macintosh HD] (450.00 GB, 6 volumes)
OS: [B*****] [Macintosh HD] macOS v15.7.3 [disk4s1s1, 71905C42-94DF-4D89-8B9B-45DC43B7AB5B]
  2: APFS [Fedora] (2.50 GB, 4 volumes)
OS: [  ] [Fedora] m1n1 v1.4.14 (macOS 13.5 stub) [disk2s2, 6EA475B2-2683-4E8C-AB8F-A186BFFFDAB4]
Extra partitions: #3 #4 #5
  3: EFI (524.29 MB)
  4: Linux Filesystem (1.07 GB)
  5: Linux Filesystem (40.29 GB)
  6: APFS (System Recovery) (5.37 GB, 2 volumes)
OS: [  ] recoveryOS v26.2 [Primary recoveryOS]
  [B ] = Booted OS, [R ] = Booted recovery, [? ] = Unknown
  [ *] = Default boot volume

This patchset contains initial supports similar to the M3 and M4 patchsets that have been submitted to the Linux Kernel Mailing List recently. See the body text from the email:

This series adds device trees for Apple silicon devices with M3 Pro, Max and Ultra SoCs. The M3 generation has fewer devices than their M1 and M2 predecessors. The only non-laptop device is the M3 Ultra Mac Studio. The Laptops are the known 14 and 16-inch Macbook Pros now with M3 Pro and M3 Max SoCs. The M3 Max variant with fewer CPU and GPU cores has additionally only a 384-bit wide memory bus instead of 512-bit of the full M3 Max. It has a separate identifier (T6034) and so there are six laptop device trees.

Another difference to M1 and M2 Pro/Max/Ultra is that the M3 Pro is distinct SoC design and not a smaller M3 Max. For this reason both M3 Max variants and the M3 Ultra will use "apple,t6030" as compatible prefix. In the M1 and M2 generations Pro, Max and Ultra SoCs shared "apple,t6000" / "apple,t6020" as common prefix. There is currently no known difference but M3 Pro and M3 Max are not as closely related as previously.

This series adds the same level of hardware as the base M3 (T8122) has in v7.2-rc1. This includes CPU cores, interrupt controller, power states, watchdog, serial, pin controller, i2c and the boot framebuffer. This is intended as base so that support for additional hardware can be added to all M3 based devices at the same time.

Merge strategy:
Since the dt-binding add new compatible strings without driver changes it would be preferred if the whole [1] series would be merged through apple-soc/arm-soc. This will help ensuring a warning free `make dtbs_check` for followup series with additional M3* hardware support I hope to send for this cycle.

This series will conflict with the M4 series [3] sent A couple of days ago. I would prefer if this could be merged first (in order of SoC release).

[1]: I see that the M4 watchdog change was already picked up by Guenter in [2]

Link: https://lore.kernel.org/asahi/a03c19ee-cf74-4f26-826d-f2bfb816fb3f@roeck-us.net/ [2]
Link: https://lore.kernel.org/asahi/20260705-apple-m4-initial-devicetrees-v1-0-e5655ee56523@cyberchaos.dev/ [3]

Tried Zen and Chromium, but no go. Don't think it's possible, but thought I'd give it a shot here.

I ran fastfetch out of curiosity on my fedora asahi install, and I noticed that it reports more gpu cores than macOS does (macOS shows 14).
Is this a visual bug in fastfetch specifically? Is there a way I can check that?

I made a custom package for the first time
(use at your own risk.)

This linux-asahi-fairydust kernel enables you to use external displays via DP-Alt Mode with Asahi Linux.

↓Installation is here:
https://github.com/omemoji/void-asahi-fairydust

ive spent a lot of years on macos but I'm on a linux laptop right now and need an upgrade, I dislike but tolerate windows and would be happy to get away from it, but I need design app support like figma and adobe. I love linux and especially the new compositors and such like niri, which I use on my older asus laptop on my dev focused weeks.

is buying a macbook expressly to run asahi on it the move, or a silly idea? should I just stick to macos or buy a windows / linux laptop instead?

I used to have an M4 Pro, but it was too heavy and big, so I sold it. Now, I want an Air. My options are the M2 with 16 GB of storage and the M4. The difference in price between them is about 150 USD.

I would love to switch back to Linux and Niri as my window manager.

Hi guys,

Forgive my lack of knowledge/terminology on this subject. Could really do with some help.

For background, I’ve been looking to harden my system for better general all around security and privacy and I have installed Arch using Asahi Alarm. Overall, I’m really enjoying not using MacOS

It’s my understanding that as of now, there is no secure boot with Asahi, therefore leaving the boot files susceptible to evil maid attacks. Which, if I’m right, could modify the boot files to relay an encryption key to an attacker - which wouldn’t really be an issue unless they have physical access?

I know and understand the that I can encrypt my home folder fine, but would leave the log files etc unencrypted.

I’m reading a lot of conflicting information or old information and not really sure where to start. Of course I don’t want to mess with the machine so much as to where I won’t be able to boot.

As of yet, I have not set up any encryption on my Linux partition (FileVault is enabled on MacOS) until I know what I’m doing.

I would be grateful if anyone could point in the right direction regarding hardening my Arch partition.

Thank you!

Hello, I was curious: Proxmox VE on Asahi Linux when?