Hacker News new | past | comments | ask | show | jobs | submit login

> 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).

https://github.com/systemd/systemd/issues/2402


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.


Would it be possible to replace the internal SSD? Possibly by setting some laxer security policy before the original one dies?


I am certain the internal SSD is soldered on--I believe the whole M1 motherboard is an SOC.


Ha, I was thinking of software restrictions and neglecting the glaringly obvious mechanical one! Thanks.


Very do-able on 2015 MacbookPros; can't imagine it's that different on the M1 mobo.


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.


Yes, desoldering the NAND is quite doable.


Except presumably for replacement with identical hardware.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: