If UEFI Secure Boot is enabled, Fedora kernels detect this and lockdown. And hibernation is then disabled. The reason is lack of an autheticated hibernation image. This work has had several proposals but still isn't implemented.
I'm not sure of the status on other distro kernels but allowing it would be a significant bypass of Secure Boot's purpose.
This exact thing is irrelevant to Asahi; the reason they don't support suspend-to-disk is that their drivers don't support full reconfiguration. This is a difficult task, as is "true suspend," because Macs have tons and tons of peripheral SoCs running firmware with their own SRAM, so resuming from suspend or hibernate creates a delta between the firmware state and the system state. (and, before the usual Apple trolls show up, this is true on x86 lately too, but on x86 the driver and platform interface is more standardized to support these kind of state changes without as much OS support).
Needing a way to securely verify the hibernate image is ALSO a problem, and one of the reasons Asahi haven't focused on suspend-to-disk, but it's not the first-order issue.
You can always set the system up to boot in insecure mode via shim, even if UEFI Secure Boot is active. It requires an explicit configuration step with physical presence, but it's doable.
Macs allow the device owner to install an OS that isn't signed at all, without having it degrade the security of the system when you do boot into MacOS.
Fine, but can it be disabled? If secure boot is interfering with another function of the computer, the owner might decide they prefer hibernation over secure boot.
I think what you're missing is that "secure boot" isn't a system-wide on/off thing on a Mac, it's a per-OS thing. And UEFI Secure Boot specifically is something that only exists on a Mac to the extent that Asahi shoehorns it into a system that doesn't natively do anything UEFI-related. It would be very surprising if Asahi Linux didn't still provide a way to skip their UEFI Secure Boot code paths and just plain boot.
Yes, but that's not a perfect excuse since OpenCore (and Clover) exists. macOS very well can boot without iBoot's opaque "man behind the curtain" blobs, Apple simply never entertained it as an option on their chips. Apparently important stuff is happening in that boot process and they can't have you emulating it for fun or profit.
That is worth discussing though, as it's a marked departure from old Macbooks that did support the UEFI method.
I don't think suspend to disk is properly supported in Asahi. I remember looking into it a couple of years ago and found that it wasn't a solution, and a quick Google search now indicates that it's still not implemented.
> Getting hibernate to work would mean a metric truckload of work on the drivers to support restoring firmware state. Not happening any time soon, it's basically forever the bottom of the priority list and we're unlikely to ever run out of other things to work on first.
> Fixing PM with no documentation is a game of trial and error. You do "more things" like macOS and hope that one of them reduces power consumption.
> It definitely isn't obvious what we're missing, and we don't know what the real answer is going to be. If we did, it would already be fixed.
Suspend-to-disk (or rather, suspend-then-hibernate) is notoriously unreliable on Linux. Hell, its occasionally unreliable on Windows and OEMs taper their firmware to Microsoft's spec and quirks.
I think buying a year old laptop helps give time for the quirks to get worked out in the kernel.
I was able to follow a fairly standard NixOS config with lvm and encrypted swap. I've never had any issues after hibernating a couple times a day for 3 years.
I don't know what the fuck is going on with laptop hardware. That stuff seems to barely work, despite the chips and stuff being off the shelf. Most windows laptops cannot handle sleep correctly either.
All the Lenvo laptops I've bought for personal use and the HPs my work gets have fully functional sleep under windows. The Lenovos also sleeps just fine under Linux. Wonder if its really specific brands that don't put the effort into their HW or drivers support for sleep?
My Lenovo would just randomly kill its battery even when it was supposed to be full suspend-to-disk - under Windows.
Setting the BIOS option to "Linux-compatible sleep mode" fixed this, but it took me FOREVER to figure this out and I'm reasonably certain I first heard about this fix in a comment here.
The existence of a BIOS option called "Linux-compatible sleep mode" is a dead giveaway that the default behavior is enshittified sleep that wakes up your system periodically so it can check your email, phone home to Microsoft, and maybe fail to go back to sleep.
Having such an obvious name like that is a gift, because otherwise you have to start decoding Intel Marketing names for their features to figure out which are actually anti-features.
Much as I might wish this were really the case, the truth is that it wasn't Windows' fault - IIRC from the explanation, Windows supports sleep modes that Linux doesn't, but it doesn't support them very well, and it's apparently not a rare issue. Something to do with S3 sleep mode IIRC.
The blame is shared between Microsoft and Intel. It's not really that Windows supports sleep modes that Linux doesn't, but that Microsoft and Intel conspired to get rid of S3 sleep mode entirely.
The intention was to replace S3 with fine-grained per-device sleep modes that would in aggregate lead to idle power that is almost as good as S3 while allowing for the "wake up and check email" kind of features. But to the surprise of approximately nobody, this complex multi-vendor strategy relying on high-quality drivers for every single peripheral in the machine did not work out as well as planned. The plan also did not in any way require that S3 sleep be eliminated from newer hardware platforms; that was just malicious behavior from the Wintel conspiracy.
My Asus laptop with 32 GB of RAM is 4 years old, but resumes from the encrypted swap partition in under 5 seconds, which is fast enough for me.