Asahi Linux stuck/reboot on Fedora Spinner

Our Neighbors Asahi Linux Ask Asahi
1

Hey,
I am new to the Linux world but really want to get in and dualbooted my Mac M1 with Asahi Fedora. Everything worked fine, I then shut my laptop down. After two hours I wanted to start it and it stuck on the after that U-Boot screen, where it show a loading spinner and fedora underneath (picture attached). The spinner spinned, then the screen got dark, i turned it on again, the spinner was still spinning and the it just rebooted. I then booted into Mac Os again, was not able to solve the problem and then uninstalled and reversed my Dualboot Linux (don’t know how to call this). I reinstalled Asahi Fedora, this time it worked fine, i shut down my laptop, turned it on again could login, but then i restarted it and the same problem accured. What is this and is there help?
I really would love to make it work.

thanks:)

IMG_0995
IMG_09952565×2352 777 KB

2

Welcome to Fedora @kurtgoedel

What is the equivalent of ESC by your computer? Just press that when starting and you get a list of tasks while the spinner is running. This might gives you more information what is wrong.

3

did you solve it? I have the same problem haha

4

I am also facing a similar issue (possibly related). Mine appears to be intermittent (usually boot looping) however, I was able to get in once and change my grub settings to get some actual output (by removing rhgb quiet).

PXL_20260327_175839607
PXL_20260327_1758396071415×1061 449 KB

I pulled dmesg info from a proper boot (where I was actually able to get into Fedora) and appears to match up pretty well:

[    1.457339] asahi 206400000.gpu: GPU Information:
[    1.457339] asahi 206400000.gpu:   Type: G13G
[    1.457341] asahi 206400000.gpu:   Clusters: 1
[    1.457341] asahi 206400000.gpu:   Cores: 8 (8)
[    1.457342] asahi 206400000.gpu:   Frags: 8 (8)
[    1.457343] asahi 206400000.gpu:   GPs: 4 (4)
[    1.457344] asahi 206400000.gpu:   Core masks: [
                   0xfe,
               ]
[    1.457345] asahi 206400000.gpu:   Active cores: 7
[    1.457345] asahi 206400000.gpu: Getting configuration from device tree...
[    1.457370] asahi 206400000.gpu: Dynamic configuration fetched
[    1.457623] asahi 206400000.gpu: MMU: IO map: 0x204d00000:0x1c000 -> 0xffffffaf00000000
[    1.457627] asahi 206400000.gpu: MMU: IO map: 0x20e100000:0x4000 -> 0xffffffaf00020000
[    1.457629] asahi 206400000.gpu: MMU: IO map: 0x23b104000:0x4000 -> 0xffffffaf00028000
[    1.457631] asahi 206400000.gpu: MMU: IO map: 0x204000000:0x20000 -> 0xffffffaf00030000
[    1.457633] asahi 206400000.gpu: MMU: IO map: 0x23b2e8000:0x4000 -> 0xffffffaf00054000
[    1.457635] asahi 206400000.gpu: MMU: IO map: 0x23bc00000:0x4000 -> 0xffffffaf0005c000
[    1.457636] asahi 206400000.gpu: MMU: IO map: 0x204d80000:0x8000 -> 0xffffffaf00064000
[    1.457638] asahi 206400000.gpu: MMU: IO map: 0x204d60000:0x4000 -> 0xffffffaf00070000
[    1.457639] asahi 206400000.gpu: MMU: IO map: 0x200000000:0xd8000 -> 0xffffffaf00078000
[    1.457641] asahi 206400000.gpu: MMU: IO map: 0x23b738000:0x4000 -> 0xffffffaf00154000
[    1.458708] asahi 206400000.gpu: RTKit: Initializing (protocol version 12)
[    1.486374] [drm] Initialized asahi 0.0.0 for 206400000.gpu on minor 1
[    1.492606] apple-display-crossbar 38304c000.mux: Switched dpphy to disconnected state
[    1.492611] apple-display-crossbar 38304c000.mux: Switched dpin0 to disconnected state
[    1.492614] apple-display-crossbar 38304c000.mux: Switched dpin1 to disconnected state
[    1.495448] apple-display-crossbar 50304c000.mux: Switched dpphy to disconnected state
[    1.495452] apple-display-crossbar 50304c000.mux: Switched dpin0 to disconnected state
[    1.495455] apple-display-crossbar 50304c000.mux: Switched dpin1 to disconnected state
[    1.497971] /soc/i2c@235010000/usb-pd@38/connector: Fixed dependency cycle(s) with /soc/phy@383000000

It looks like the next text after this is related to another connectorthen some BTRFS mounting? :

[    1.499934] /soc/i2c@235010000/usb-pd@3f/connector: Fixed dependency cycle(s) with /soc/phy@503000000
[    1.506124] BTRFS: device label fedora devid 1 transid 331 /dev/nvme0n1p6 (259:6) scanned by mount (600)
[    1.506561] BTRFS info (device nvme0n1p6): first mount of filesystem 19215083-d0bc-45e5-ae3f-eebb4aa97385
[    1.506569] BTRFS info (device nvme0n1p6): using crc32c (crc32c-lib) checksum algorithm

@ilikelinux, any ideas based on that information?

Thanks!

5

Just an update. I have tried other installs of Asahi (Gnome and Minimal) and experience the same symptoms. With and without a power adapter plugged in (with nothing else plugged in).

I have also tried

sudo dnf upgrade --refresh

&

sudo dnf update

&

sudo asahi-fwupdate

But even then, more often than not, I experience a freeze in the boot process but not always in the same space. (Sometimes it is after apple-display-crossbar sometimes it is a few messages later).

If anyone has any suggestions, I am all ears.

6

I have the same exact problem on my M1 Mac mini. I use Asahi Fedora Server. What I do is in grub hit “e” to edit. Then I do something innocuous like add “boot_delay=10” to the end of line that starts with “linux”.

Going into the editor, lingering there for awhile, and changing something small seems to reliably allow it to boot properly. The next time you boot use a different value. Keep the value small to avoid lengthy delays.

I don’t know if it is a timing thing or if some corrupted value is permanently cached somewhere and altering that file makes the machine ignore the problematic cached value.

The process sounds tedious and annoying but at least you will be reliably able to boot into Fedora Linux. I have a server and rarely reboot. But now I have to have a keyboard, mouse, and monitor all permanently attached to my server. Also if you are using an M1 Mac mini the keyboard seems to need to be connected to the USB C port in order to work. USB A does not work for me, at least.

7

Upgraded my M1 mac mini to Fedora Server 44 Linux 7.1.13-402.asahi.fc44.aarch64+16k. It reboots fine now.

8

Hi @odero ,

Thanks for the data point. Sorry I missed your initial reply (I was on holiday).

I think this must be a different issue. The original issue I think is documented in Unreliable boot on MacBook Air M1 (j313ap) with kernel >= 6.18.10-402 · Issue #465 · AsahiLinux/linux · GitHub.

Workaround is to add modprobe.blacklist=phy_apple_atc to your kernel arguments. Keep in mind, this disables USB however.

Thanks!