Progress Report: Linux 7.1 - Asahi Linux
Blog
Progress Report: Linux 7.1
Progress Report: Linux 7.1
Previous
Linux 7.1 is now here, and of course with it comes another progress report. We’ve got M3<br>progress, Apple bugs, and more!<br>Welcome back Master Boot Record<br>When you long-press the power button on your Mac to bring up the boot picker (or use the<br>Startup Disk application), what you see listed as Asahi is not actually the partition<br>with the operating system on it. Apple’s boot tooling will only work with what it considers<br>to be a “valid” macOS installation inside an APFS container. So that we can use Apple’s<br>bootloader and avoid needing users to run commands from Recovery every time they want to<br>use Asahi, the Asahi Installer creates a small APFS container (2.5 GB) with just enough<br>of macOS on it to convince Apple’s tools that it is a bootable installation of macOS with<br>m1n1 as its kernel. This arrangement worked completely unchanged from macOS 12 to macOS 26,<br>and Apple even fixed a couple of bugs in their tools that are only encountered when attempting<br>to boot raw binaries that are not a real XNU kernel.<br>Shortly after the release of the macOS 27 Golden Gate developer beta however, we began<br>receiving reports that people were no longer able to boot into Linux on their<br>machines — the option had simply disappeared from both Startup Disk and the boot picker!<br>Obviously this is quite concerning, and so we made investigating this a priority.<br>Inspecting the disk using diskutil revealed that all Asahi-related partitions were still<br>present on the disk after upgrading to macOS 27. No data loss was occurring, which is a<br>positive sign. Additionally, Asahi was still bootable on the same machine when using the<br>boot tooling from a second install of macOS 26.<br>chaos_princess began inspecting Apple’s own macOS Installer and old streams from way back<br>when we were first poking at Apple’s boot tools. The macOS Installer sets some APFS<br>metadata before rebooting the machine, which further investigation revealed to be a flag<br>that marks the volume as bootable. Until macOS 27, the boot tooling simply ignored this<br>flag entirely. After setting the flag manually on an Asahi APFS container, it becomes<br>available in the macOS 27 boot picker with no further changes.<br>Going forward, all new Asahi installs will have this flag set automatically by the<br>Asahi Installer. We’ve also added an installer mode that will fix existing installations.<br>If you’ve installed the macOS 27 developer beta and cannot access your Asahi install, please<br>run the installer again and use the “Fix macOS 27 boot picker compatibility” option.<br>chaos_princess has also developed a program that can be run from Linux to fix the issue.<br>While we would eventually like to deploy this fix automatically, we need more testing<br>data to confirm that it is reliable and will not destroy anyones’ filesystems. That’s where<br>you come in. If you are willing to help us test this, clone this repo,<br>then build and run it from Linux before upgrading to macOS 27. If your Asahi volume<br>is still selectable as a boot target from macOS, it has worked. Do be sure to let us<br>know how it went by popping in to one of our channels<br>on OFTC or Matrix, especially if you run in to any issues.<br>Three bytes forcing shutdowns<br>macOS 27 also brings firmware updates for all peripherals with global firmware, including<br>the SMC. One of the SMC’s myriad functions is battery management. Our Linux power supply<br>driver talks to the SMC to get information such as charge state, voltage, time until empty and<br>battery health. The driver also uses the SMC’s firmware interface to configure charge<br>start and stop thresholds to prolong the life of the battery. macOS 27’s SMC firmware<br>changed one of the battery management interfaces from returning a 32-bit integer to<br>returning a single byte. This change confuses our driver, which under certain conditions<br>considers the battery as having failed and initiates an emergency shutdown to protect<br>the system. We have already patched this in the downstream kernel; starting with version<br>7.0.12, the power supply driver can deal with both firmware ABIs.<br>On installing betas<br>Bugs like these are an important reminder that developer betas are just that, developer<br>betas. It is ill-advised to install them on production machines. The two issues we<br>have had so far have luckily minor, but that doesn’t mean that all future issues will<br>be too. Global firmware updates are effectively permanent too, and can only be rolled<br>back with a DFU restore of the machine. Please refrain from installing developer betas<br>going forward. We have sacrificial machines we use to test these things on your behalf,<br>there is no need to risk your own expensive hardware and important data.<br>The more things change…<br>Designing and validating computer platforms and the ICs that go into them is extremely<br>expensive and time...