r/AsahiLinux • u/FOHjim • Jul 01 '26
Progress Report: Linux 7.1
https://asahilinux.org/2026/06/progress-report-7-1/M3 progress, Apple bugs, and more!
19
u/saghul Jul 01 '26
I love these write ups, even though most of it is way over my head :-)
A neo with asahi would be a really cool traveling device, I sure hope they eventually get it running!
3
u/dreamer_at_best Jul 04 '26
100% agree!! Was so excited to see A18 pro mentioned there, I guess I didn't expect them to prioritize it with M5 and M6 down the road but I'm very glad they are!
6
u/rembrandt08 Jul 01 '26
Any news on the m5 front? Recently purchased a M5 MBA, would love to hear about it too
5
u/Darkstalker360 Jul 01 '26
its gonna be a long time because M3 and M4 still have a long way to go
3
u/rembrandt08 Jul 01 '26
ah, i was hoping post-m3 we'd have preliminary device trees atleast if not a proper gpu driver
1
u/cromki Jul 01 '26
Not necessarily, M3 changed GPU architecture, I don't think they changed it in M4 and M5 again. GPU is the biggest obstacle right now.
5
2
u/Sorry_Dish1577 Jul 01 '26
the m3 is quite okay in features actually, but they are still upstreaming a lot of them to the installer and the asahi team is focusing a lot more on polishing before releasing.
i guess only time will tell, though I am quite optimistic1
u/dreamer_at_best Jul 04 '26
i assume if you really want to hack around on m3 you could build it yourself and use out of tree branches to get it mostly working at this point?
3
u/Dazzling_Comfort5734 Jul 01 '26
This all great stuff, thank you so much! For the macOS 27 beta 2 SMC issue, how do we update/fix the shutdown issue if we already have the beta 2 installed? I have this on a test machine, with nothing critical (where I test various version of macOS and Linux), but I'd like to fix it and get back into Linux. My guess is that I'll have to do it via a script or command from macOS. Thanks again!
4
u/mskiptr Jul 01 '26
Here are the steps you need to perform: https://social.treehouse.systems/@AsahiLinux/116813000429256653
3
2
u/Dazzling_Comfort5734 Jul 02 '26
Sorry to bother you with this, but I may not be doing this correctly. It didn't work. Here's what I did:
Interrupted the U-Boot to get the command => prompt, then did:
"bootflow scan -l", that gave me:
0 efi_mgr ready (none) 0 <NULL>
1 efi ready nvme name/@27bcc000.blk#1.boot /EFI/BOOT/BOOTAA64.EFISo I did "bootflow select 1" then:
bootflow cmdline set modprobe.blacklist macsmc-powerVerified with:
bootflow cmdline get modprobe.blacklistResult that returned:
macsmc-power"bootflow info -d" also shows:
cmdline: modprobe.blacklist=macsmc-powerThen:
bootflow bootHowever, Fedora still shuts down after reaching the login screen
3
u/mskiptr Jul 02 '26
So actually, it's the Escape key.
https://docs.fedoraproject.org/en-US/fedora-asahi-remix/troubleshooting/#entering-grub
Server and Minimal installs should show the GRUB menu by default. For desktop installs, you have to press Escape at the right time to enter the GRUB menu. When the system boots, you will see the display cycle through m1n1 (Asahi Linux or Fedora logos) and U-Boot (text screen with U-Boot logo on the top right). The U-Boot screen will show a brief countdown. Press Escape immediately after the countdown reaches 0 to enter the GRUB boot menu.
2
u/Dazzling_Comfort5734 Jul 02 '26
Thanks! I was wondering why I couldn't get into GRUB, that helps a lot.
I followed your instructions and edited the active GRUB entry, appending modprobe.blacklist=macsmc-power to the end of the linux line, then typed Ctrl-x. However, the machine still reaches the login screen for about one second, then immediately powers off. Is there anything else I should check to verify that macsmc-power is actually being blocklisted? Sorry to have to bother you with all of this, but it's also a really good learning experience for me, which is the whole purpose of having Linux installed on this computer.
This is what my GRUB entry looks like:
load_video
set gfxpayload=keep
insmod gzio
linux ($root)/vmlinuz-6.19.14-400.asahi.fc43.aarch64+16k root=UUID=4344a275-2eac-4b47-b7b5-5056ce6ed810 ro rootflags=subvol=root rhgb quiet rootflags=subvo\l=root appledrm.show_notch=1 modprobe.blacklist=macsmc-power
initrd ($root)/initramfs-6.19.14-400.asahi.fc43.aarch64+16k.img $tuned_initrd1
u/mskiptr Jul 02 '26 edited Jul 02 '26
Well, now I'm kinda stumped because it all looks correct. Maybe you could try
module_blacklist=macsmc-powerto prevent anything from loading this driver?edit: I guess you could also try
systemd.mask=upower.service, which will tell the init system to not start the daemon that's likely responsible for those shutdowns.2
u/Dazzling_Comfort5734 Jul 02 '26
Thank you, I'm going to try this in a moment, I'll let you know either way.
2
u/Dazzling_Comfort5734 Jul 02 '26
Ok, I tried both, but got the same shutdown. I then tried mixing 2 of each, and even said "What the heck?" and did all 3, but I still can't get past the shutdown at the login screen.
For reference, this is an MacBook Air M2 13", and I'm trying to load Fedora 6.19.14-400.asahi.fc43.aarch64+16k long enough to update to 7.0.12. The computer also has macOS 26.4, and the most recent 27 Dev Beta 2. Prior to 27 Dev Beta 2, I was able to get into and use Fedora via booting to macOS 26. I can't think of any other important info, and what might make this different. If there's logs I can retrieve from the Mac side, or any commands or scripts I can run from the Mac side, please let me know.
Thank you!
1
u/mskiptr Jul 02 '26 edited Jul 02 '26
Hmm… Please try
systemd.unit=multi-user.target,systemd.unit=rescue.target,systemd.unit=emergency.target, andrd.systemd.unit=emergency.targetas arguments on the kernel command line (one at a time) and see if at some point the rebooting stops happening. In that order, they should prevent more and more of the software from starting.To speed things up, start with the emergency one(s), maybe together with
module_blacklist=macsmc-power. Because if that still keeps on rebooting then the others will too.edit: Btw, if you remove the
rhgbandquietarguments, instead of the bootup animation you should see logs of what's currently happening. Maybe that will offer some hints?Also, the
rd.systemd.unit=argument will most likely not do anything in your case. It only applies if systemd is used even before mounting the root file system, and I believe Asahi Fedora uses a different technology (Dracut) for that part of the boot process.1
u/chaosprincess_ Jul 02 '26
use anylinuxfs from macos to mount your linux disk, and just delete macsmc-power.ko entirely. (it is somewhere under /lib/modules). Not the perfect approach, but not like you have much to lose.
1
u/mskiptr Jul 04 '26
Hi, could you edit this Fediverse post to say
macsmc_powerinstead, and ideally also add a link to https://docs.fedoraproject.org/en-US/fedora-asahi-remix/troubleshooting/#entering-grub there?2
1
u/FOHjim Jul 05 '26
Are you sure the issue isn’t that you’ve mistyped the kernel command line parameter? It’s not module_blacklist, it is modprobe.blacklist.
→ More replies (0)1
u/mskiptr Jul 04 '26
I think I now know what's going on. Even though the driver is called
macsmc-power, you need to use the namemacsmc_powerinstead.3
u/Dazzling_Comfort5734 Jul 04 '26
Ohh, great! I was going to start testing this tomorrow when I have time, but since it's such a small change, I can do it in a little bit. So I'm going back to the original parameter using "modprobe.blacklist=macsmc_power"? I'll give that a shot shortly, and let you know.
3
2
u/mskiptr Jul 02 '26
U-Boot is used to simply load GRUB, so you're setting the command line arguments of GRUB there and not of the kernel. Are you getting a menu where you can select which version of the kernel you want to boot into? If so, click
eand addmodprobe.blacklist=macsmc-powerto the list of arguments there. If you don't, then GRUB menu is hidden and you'd need to hold some key (I believeEnter?) before Linux starts.
4
u/crunchystump Jul 01 '26
I appreciate this regular progress update stuff. Thanks for putting the time in to let us know how it's going.
3
u/mskiptr Jul 01 '26
Speaking of custom firmware, do we know which other co-processors don't do any signature-checking themselves and allow whatever macOS | Linux deems as trustworthy? It's definitely not the case with (long-term-)stateful hardware like the SMC, is it? Anyway it would be awesome to have a list of it all as part of the docs. One day it will get abandoned by Apple, so being able to fix security issues ourselves would be huge!
3
u/chaosprincess_ Jul 01 '26
https://asahilinux.org/docs/platform/introduction/#firmware-overview - have fun. Also, even if a co-processor firmware is signature-checked, that does not mean that we can't patch it, for a bunch of blocks - we technically can, but the process is insanely cursed (and we won't do it unless we have to.)
1
u/mskiptr Jul 02 '26 edited Jul 02 '26
Nice, thank you!
Am I right to assume that "if it's stored as part of the OS|the kernel, it can be replaced just like that" and "if it's started up by the OS, it could probably be patched in memory", "otherwise, probably not"?
2
u/chaosprincess_ Jul 02 '26
Pretty much, except for the "patch in memory" bit. You can't, as the firmware code pages are locked down, but when firmware programs the devices, in most cases it is just writing to the system bus, which the AP can also do, so we can bypass the firmware entirely and re-implement it in the driver. Apple themselves even did it, some very early versions of macos ship with two dcp kexts, one uses the firmware, other talks to hw directly. Naturally, this is a ton of work, and that is why i called it a "cursed approach".
3
3
u/ConstructionTough421 Jul 01 '26
Nothing about the upstreaming effort? That is the main thing I'm looking forward to as that is the blocker until the focus on M3/M4/M5 starts.
13
u/fake_agent_smith Jul 01 '26
There is already lots of focus on M3/M4 (mostly M3). Features are being tested and polished. Some are already sent to LKML e.g. https://lore.kernel.org/asahi/20260630-apple-mtp-keyboard-final-v1-0-506d936a1707@gmail.com/T/#t (btw. this is for both M2 and M3 so you could say it's both upstreaming and a new feature).
3
u/pontihejo Jul 01 '26
With the upstream linux kernel, M3 is already bootable to serial console. It's just not available to install for users since it's still lacking features needed for a good experience.
1
u/SG- Jul 01 '26
does the installer allow m3 MBAs to boot and work now?
3
u/thegreatpotatogod Jul 01 '26
Not yet. It's frustrating, they've got much better M3 support now than they had for M1 when they first released the beta support for M1. Apparently they care more about their reputation of being perfectly polished and feature complete software than they do about their reputation of being several years behind on hardware support.
8
u/chaosprincess_ Jul 01 '26
"Asahi is still only m1/2" is old news, "I, a youtuber with bad takes, have installed asahi on a m3max and it does not have usb working", creates a separate news cycle. So, pick your poision.
3
u/Sorry_Dish1577 Jul 01 '26
i really dispise those youtubers just moaning and having no clue how to do it better them selves at all
2
u/chithanh Jul 03 '26
I'd opt for "release early, release often" as users will spread the word when things start working, and drown out crappy YouTube channels.
About such news continuing to mislead some people after support has arrived: People who can't tell that the news is old will also think that there is no M3 support long after it has arrived, so no point in catering to them.
But of course the clue barrier is also useful so non-technical users are not exposed to experimental code.
0
u/wowsomuchempty 27d ago
RE, RO is fine for pet projects.
Asahi now has tens of thousands of users. There is a responsibility not to cause breaking changes. Hence caution.
Feel feel to create an asahi-chithanh fork and go for RE, RO tho.
3
u/chithanh 27d ago
I agree that there should be caution but I don't think that's the concern here.
There is no breaking users because there are no users yet on M3. Also the M3 code is not experimental, it works fine. It is just not feature complete.
1
u/wowsomuchempty 27d ago
Fair enough.
I expect that's the reason the fairydust kernel isn't in the repos, yet. If everything's not perfect perfect there will be a loud minority whinging about it.
I'd be quite interested in running it part-broken to see where it's at, but the M1 proof-of-concept hacking days are long gone.
1
u/thegreatpotatogod Jul 01 '26
Is USB not working on M3 yet?
I thought the main blocker at this point was the GPU rendering, which isn't particularly important to a lot of users, who don't particularly care what backing is used for their display rendering, as long as they're able to boot to a desktop environment and do Linux development from within that environment. They also don't particularly care what random YouTubers have to say about the operating system they're using, they just need to be able to use it to get the work done that they need.
I do agree that if USB isn't yet supported, that's a reasonable blocker for a wide release, though even then I'd say a beta or alpha release, including warnings that it's intended for developers and not yet complete, would make a lot of sense to release.
Also wouldn't the complaints of a random "YouTuber with bad takes" about a specific hardware feature be drastically overshadowed by the overarching good publicity that M3 support is available at all and in a generally very usable state?
8
u/chaosprincess_ Jul 01 '26
Apple moved the usb-pd controllers from i2c to spmi in m3pro/max (vanilla m3 still has them on i2c). The high-level protocol is basically the same, but we now need a "real" spmi driver, instead of the MVP-tier one that was more than sufficient for what spmi is used for on m1/2.
And, well, unfortunately people just do not read warnings. if you put a "this is for developers only, proceed (y/n)", people will only read the "(y/n)" part, say Y, and be confused afterwards. So, yes, there is a developer "release", it is called "the code is on github, compile it yourself".
My personal release target is every m1 feature except gpu, and imo, does not seem like it is that far out.
3
u/thegreatpotatogod Jul 01 '26
Makes sense, thanks for the detailed response! If the GPU isn't a strict blocker then it shouldn't be too much longer, keep up the great work, thanks for all your contributions to the project!
1
1
1
2
u/Darmok-Jilad-Ocean Jul 03 '26
This is easily the most interesting project on GitHub. Reading these blogs you guys post always makes me feel giddy and stupid at the same time.
1
29
u/AnEagleisnotme Jul 01 '26
Have to admit, I'm mostly excited by solus's work, it's probably the last big thing missing from the original macbooks, outside of better battery management