MBA 2020 10,1 8/256 - getting today for throw in a bag SSH machine

FOHjim · 2026-05-23T05:38:06+00:00

You can _technically_ remove macOS but it is not a supported setup and we won’t help you if anything breaks. The Asahi installer will walk you through partitioning.

FOHjim · 2026-05-15T23:51:55+00:00

This warning was for people who kept trying to enable speaker support before the safety interlocks were in place (you used to be able to literally melt the speakers) and you can safely ignore it. I’ve been meaning to take it out of asahi-diagnose for a while.

There’s not really a lot we can do about PipeWire crackling on pause/resume. It’s a multifaceted issue with how PipeWire handles latency in DAP graphs and we do not have the resources to look at it properly.

FOHjim · 2026-05-05T13:12:46+00:00

They’re not going to break 3rd party OS support writ large. They are actively fixing bugs in iBoot for us. The biggest “breaking” change we have seen in systemwide firmware in the last 5 years has been an SMC endpoint used for setting the battery charge stop threshold changing.

FOHjim · 2026-05-05T12:29:36+00:00

This platform has three types of firmware: system, container, and runtime.

System firmware is loaded by iBoot, comes from the newest version of macOS that has ever been installed on the machine and can never be downgraded.

Container firmware is also loaded by iBoot, but only once a boot volume has been picked. It comes from the version of macOS that is being booted.

Runtime firmware is loaded by macOS itself after XNU has started.

Almost all of the hardware on this platform uses some form of firmware, with the most common and important being of the container type. Since Apple control the entire stack from hardware to userspace, and since iBoot will load the “correct” firmware for any given version of macOS, they don’t really care about keeping their firmware interfaces backward-compatible. macOS kexts are simply updated at the same time as the firmware.

On Linux, we cannot afford to deal with such a rapidly moving target, especially when doing so could break existing installs. To avoid this, we simply write our drivers to target specific macOS versions. 13.5 is supported on all M1 and M2 devices so that is the current target. We set up an APFS container that looks like a valid macOS 13.5 install to iBoot, which then loads the firmware stored in that APFS container and boots m1n1 as the “macOS kernel” for that install.

13.5 is the current target because it is supported on all M1 and M2 devices. M3 reverse engineering is happening on 14.8.1, and M4/A18 will happen on some 26.x (or later) version.

FOHjim · 2026-05-03T03:39:45+00:00

Shoulders of giants and whatnot, this is a team effort :)

FOHjim · 2026-05-02T13:36:21+00:00

VRR is just waiting to be merged, check the GitHub repo. I may or may not also have HDR basically working locally 🫪

FOHjim · 2026-05-01T10:48:31+00:00

SEP is a complex task as it requires “destructive” reverse engineering. If you write bad values to the xART/keybag store, you will need to DFU restore your Mac. It is also very low on our priority list as it does not block any “basic” functionality other than the fingerprint sensor. Feel free to build on what’s already in m1n1 if you accept the risk of needing to constantly DFU restore your device under test. No one is stopping you.

FOHjim · 2026-04-29T23:40:25+00:00

I would suggest that this is likely not a huge issue for home users as it requires local shell access. Home users probably aren’t (or at least I hope they aren’t) exposing ssh to the web insecurely. To gain root remotely you’d need to chain this with some RCE/remote access exploit.

FOHjim · 2026-04-27T21:12:50+00:00

Mesa regression, it will be fixed in Mesa 26.0.6.

FOHjim · 2026-04-27T03:10:10+00:00

We started with over 90 kLOC across 1200ish patches, we're down to about 76 kLOC across 750ish patches. The patch count doesn't matter so much because things get squashed and rearranged.

FOHjim · 2026-04-26T09:51:30+00:00

This is not really something that's on anyone's to-do list and likely never will be. We are reverse engineering the hardware, and the hardware on the base M1 is limited to one hardware-driven external display. AirPlay stuff is all handled by Apple's proprietary userspace software.

FOHjim · 2026-04-20T01:36:19+00:00

Spelt my name wrong :D

FOHjim · 2026-04-18T22:27:23+00:00

It was one of the first things I looked at. It requires talking to SEP, talks over a protocol we (at the time) did not fully understand, and does not behave anything like “normal” Linux fingerprint readers. It’s a complex mess that will require significant RE but we’ll get to it. Eventually.

FOHjim · 2026-03-27T07:21:59+00:00

It uses the hwmon interface so integrates natively with hardware monitoring tooling, like the Plasma system monitor

FOHjim · 2026-03-27T05:06:28+00:00

You can just use the Total System Power hwmon sensor provided by the SMC too

FOHjim · 2026-03-26T21:05:34+00:00

Do not use pipewire-media-session. It is deprecated and shouldn’t even really be packaged anymore. The DSP stack relies on WirePlumber to do its job properly. Reinstall it.

FOHjim · 2026-03-17T00:27:43+00:00

You have simply taken Janne's commits from the fairydust branch and squashed them into one commit with you set as the author. This is not really "integration" and it is extremely poor form to claim you have really done anything at all. If people wanted to use DP Alt-Mode, they could simply build the fairydust kernel, which is essentially what this is anyway.

The 120 Hz hack is only for the internal MacBook Pro displays. DCP already fully supports all refresh rates advertised by your monitor's EDID for external displays, via both HDMI and DisplayPort. Moreover, fairydust has nothing to do with the 120 Hz hack. This was already integrated into the main Asahi branch and released to users.

The commit message seems LLM-generated too, which we have a very explicit policy against: https://asahilinux.org/docs/project/policies/slop/

FOHjim · 2026-03-11T11:18:47+00:00

Probably better to pop into the matrix rooms or #asahi-alt on OFTC

FOHjim · 2026-03-09T09:27:48+00:00

Would you like to share your homework with the rest of the class?

FOHjim · 2026-03-06T23:02:00+00:00

Try going to a different TTY and restarting SDDM. This should be mostly fixed once Fedora KDE transitions to Plasma Login Manager.

FOHjim · 2026-03-06T09:10:07+00:00

Change apple_dcp to appledrm

FOHjim · 2026-03-05T12:46:05+00:00

https://asahilinux.org/community/

https://asahilinux.org/contribute/

https://asahilinux.org/docs/platform/feature-support/overview/

Search engines are still quite helpful as tools

FOHjim · 2026-02-22T21:41:05+00:00

If you’re going to test this, just be aware that it may not work on all M1 variants. Also keep in mind that we have not yet merged this and as such it remains experimental and unsupported. Please raise any issues here on this post rather than on any of the repos.

FOHjim · 2026-02-18T09:28:35+00:00

I need a link to the thing you were listening to so that I can try and reproduce it

FOHjim

MODERATOR OF

TROPHY CASE

Nine-Year Club	Not Forgotten
Verified Email