The M1 boot process is very different from Intel macs. In fact, they do not support external boot disks at all, by design. This is because the built-in firmware is extremely minimal, and does not contain drivers for anything but the internal SSD. It doesn't even have a keyboard driver, or any kind of GUI other than showing the Apple logo and "Entering startup options" text, and some error screens. All of this is by design, for security - UEFI is an enormous hairball of code, especially on Intel macs, and almost impossible to secure properly for that reason.
When you boot into the "Startup Options" menu, you are booting into a special macOS partition in the internal SSD. M1 Macs use macOS as the moral equivalent of the UEFI setup menu. That boot picker that looks like the UEFI boot picker on Intel Macs? Yeah, that's a full-screen app on macOS made to look similar.
So how does external boot work?
The "blessing" process done by the Startup Options screen involves copying the entire macOS Preboot partition - iBoot2 OS loader, Darwin kernel, auxiliary CPU/device firmwares, device tree, and some additional stuff - to the internal SSD. It then creates a local, signed boot policy that allows system firmware to boot this macOS install.
You aren't booting from an external disk. You are booting from the internal SSD, with the root filesystem on the external disk.
Additionally, the integration of the macOS user credentials with the SEP means that you can't "just" take an install made on another machine and use it on a separate one. It involves importing user credentials into the local machine. This process isn't implemented properly yet.
As you might expect, this entire mechanism introduces a ton of corner cases around updates, boot selection, etc., and it is still very buggy and broken. The M1 launch was, when you look at details such as this, very obviously rushed.
I'm actually eagerly waiting for Apple to fix this in future system firmware releases, because my plan for installing Asahi Linux for end users with a minimal amount of fuss is to abuse the mechanism to adopt foreign macOS installations. This elides the current need to have a completely wasted, 60+GB macOS install as a dummy to actually launch Linux (we could clean it up and resize it to get the space back, but it still makes for a very annoying install process that I'm hoping to avoid).
On the plus side, this dual-booting mechanism is very cleverly designed to separately secure different OSes, so you do not need to downgrade security on your machine to install an unsigned OS like Linux. It is a separate OS with a separate security policy. You can keep your macOS install fully secure, and capable of running iOS apps and other actions that require secureboot, and install Linux (or another macOS with a custom kernel, kexts, etc) in parallel, completely unintrusively. So kudos to Apple for designing this whole thing, and for opening it up for us to use :)
> You aren't booting from an external disk. You are booting from the internal SSD, with the root filesystem on the external disk.
So this means that the life of all M1 Macs is locked to the life of the internal storage, as the (inevitable) drive failure will render the whole computer unusable?
Yes. This is also the case for just about every other computer out there, as chances are most PCs will end up writing to UEFI variables on every boot for something or other anyway, and those are stored in Flash memory too, which has a finite endurance. That should be NOR flash, which should have higher endurance than the NAND in SSDs - but we also don't have any numbers on Apple's SSD endurance, so it would be premature to speculate that this is going to be a real problem in non-pathological use cases, and that the machine won't in practice die first of other causes.
Strictly speaking, the things can boot off of DFU (USB device mode) too, but to make that useful for regular boot you need to ask Apple, as currently you cannot boot a normal OS like that as far as I know, only their signed restore bundles (which is how you fix an M1 Mac if you wipe the SSD).
While technically speaking yes, eventually the firmware flash will fail, I'm not sure bad UEFI variables will actually prevent the system from booting, since the rest of firmware should be fine. I've gotten systems to boot with totally borked UEFI flash space.
It is being nitpicky on my part, but I think we're reaching the point where these machines could be expected to last long enough for SSD weardown to become a real issue, even with current flash tech. While this has theoretically been a problem for the past 5 years now, it's a bit disappointing to learn that now you can't use an external drive in the event of the (irreplaceable) internal drive failing.
That depends on the implementation. For example, I've seen many PCs exhibit a behavior where after a major hardware change, usually CPU or RAM, the system boots, shuts down, then boots again automatically. Presumably after discovering the change it wrote some variables describing it, then rebooted. Without the ability to persist that information, I would expect it to loop forever.
A counterpoint would be around 2012-14 (can’t remember exactly), when secure boot was hitting the mainstream, the Ubuntu installer (and systemd) didn’t know that UEFI anything was stored on the internal disk and would wipe it out, causing many machines to hard brick (which then made Lenovo say “uh, we don’t support Linux, tough”, which wasn’t cool).
Raw EDK2 doesn't really need variables at all (in fact if you use it as a coreboot payload, persistentce is not implemented whatsoever, at least as of.. some time ago).
Various crap bolted on by AMI and the OEMs… well, YMMV – remember these laptops where someone did rm -rf with mounted efivarfs on Linux and that bricked it because it just refused to boot without the variables :D
I can believe that sadly :/ UEFI implementations range from pretty good to absolute crap. My newest Dell has at least been mostly decent, but an older Dell has so many issues with the firmware, it's unbelievable.
Not that it (worn out flash) is gonna be a problem in practice, anyway. Neither will the M1's inability to boot without the internal drive. Like Marcan said, it's not really likely to die in realistic use within a pretty long lifespan, I just find these sorts of shortcomings/regressions ... disappointing. I get the various reasons why, it's just annoying.
The 2015 MBPs were the very last with removable storage[0]. The flash controller and NAND chips are soldered directly to the board on every newer MBP and are essentially non-replaceable, short of desoldering the raw NAND flash I suppose.
[0] The low tier 2016 and 2017 touchbar-less MBPs do, quixotically, have removable storage, but using a proprietary format vs the NVMe sticks in previous models. All touchbar MBPs (and M1 Macs) have soldered flash chips, and the TB-less ones were totally discontinued in 2018 IIRC.
Hey, I just wanted to say, I really enjoy your livestreams! Although it's way over my head for most of the time. Beyond the impressive depth of knowledge and insights, it's a very chill vibe and calm talking, nice clickety-clack ASMR-ish soundscape.
If you'd spent some time lewding your *nix (I mean window managers and color profiles and such, not half-naked anime girls), it would be perfect relaxing, nerdy ambient art, all for the format itself. (But I would settle for just the Linux on M1 thing too still ;D)
When you boot into the "Startup Options" menu, you are booting into a special macOS partition in the internal SSD. M1 Macs use macOS as the moral equivalent of the UEFI setup menu. That boot picker that looks like the UEFI boot picker on Intel Macs? Yeah, that's a full-screen app on macOS made to look similar.
So how does external boot work?
The "blessing" process done by the Startup Options screen involves copying the entire macOS Preboot partition - iBoot2 OS loader, Darwin kernel, auxiliary CPU/device firmwares, device tree, and some additional stuff - to the internal SSD. It then creates a local, signed boot policy that allows system firmware to boot this macOS install.
You aren't booting from an external disk. You are booting from the internal SSD, with the root filesystem on the external disk.
Additionally, the integration of the macOS user credentials with the SEP means that you can't "just" take an install made on another machine and use it on a separate one. It involves importing user credentials into the local machine. This process isn't implemented properly yet.
As you might expect, this entire mechanism introduces a ton of corner cases around updates, boot selection, etc., and it is still very buggy and broken. The M1 launch was, when you look at details such as this, very obviously rushed.
Further reading for those interested:
https://github.com/AsahiLinux/docs/wiki/M1-vs.-PC-Boot https://github.com/AsahiLinux/docs/wiki/SW:Boot https://github.com/AsahiLinux/docs/wiki/SW%3AStorage
I'm actually eagerly waiting for Apple to fix this in future system firmware releases, because my plan for installing Asahi Linux for end users with a minimal amount of fuss is to abuse the mechanism to adopt foreign macOS installations. This elides the current need to have a completely wasted, 60+GB macOS install as a dummy to actually launch Linux (we could clean it up and resize it to get the space back, but it still makes for a very annoying install process that I'm hoping to avoid).
On the plus side, this dual-booting mechanism is very cleverly designed to separately secure different OSes, so you do not need to downgrade security on your machine to install an unsigned OS like Linux. It is a separate OS with a separate security policy. You can keep your macOS install fully secure, and capable of running iOS apps and other actions that require secureboot, and install Linux (or another macOS with a custom kernel, kexts, etc) in parallel, completely unintrusively. So kudos to Apple for designing this whole thing, and for opening it up for us to use :)