I dont know why you ask that in the Fedora Discuss
First there was Asahi Linux, based on Arch. The next step was to get all the needed drivers and patches to a more stable distribution, Fedora, this made “Fedora Asahi Remix”.
This remix is not a Fedora spin, lab etc, as it includes a different kernel and more (but I dont know much).
The Asahi devs upstreamed a ton of patches and drivers upstream, so that now mainline Linux can run on M1 macs, but it needs to have a special page size or something.
So Debian can work, when using a custom kernel. The Debian upgrade likely replaced that kernel with the standard Debian arm64 one, which does not work.
Why is there no immutable Fedora Asahi? This scenario would not happen there…
But anyways I recommend using Fedora Asahi Linux and not Debian, as only a subset of the patches is upstreamed so it will lack much support.
I would certainly be happy to start from scratch. In fact, I did attempt to reinstall Asahi from OSX as instructed. Had to wait 13 hours + while Sonoma installed. But ultimately, I left the disk partition table alone and seem not to have effected any change.
On the plus side, I have a recent kernel 6.5.0-asahi-00780-g62806c2c6f29 … Nov 12 … 2023 aarch64, and I guess I can just remove the offending kernel for unassisted boot.
Sorry if this is the wrong venue. I did look around a bit.
This is not the wrong place. This is a generic Asahi Linux forum hosted on fedora infrastructure. Note the Ask anything about installing, using, troubleshooting, or customizing Linux on Apple Silicon platforms and Fedora Asahi Remix. in the pinned About the Ask Asahi Category post.
I suspect that during the kernel update the second stage bootloader bundle (m1n1 + device tree (hardware description) + u-boot) wasn’t updated. I believe the hardware description between 6.5.0-asahi-00780-g62806c2c6f29 and 6.6.15-arm64 is not compatible. I would expect that this is handled automatically during a kernel update. Following steps possibly fix it:
find the m1n1 directory on the EFI system partition. it should contain a boot.bin and possibly a boot.bin.old
make a backup of boot.bin on the same partition (if something goes wrong you can restore m1n1/boot.bin from macos and get at least the old kernel booting again)
run update-m1n1(if that produces any errors please paste them here)
If that changed the size/content of boot.bin a reboot into the new kernel probably works. If not the update-m1n1 script probably still picks up the device tree of the old kernel. If that is the case looking for a place with more asahi/debian knowlegde would be a good idea. I can only think of the IRC channels #asahi-alt or #debian-bananas (both on oftc.net)