Anyone checked to see if MacOS will boot on Apple T2 hardware with Secure Boot disabled?
(I’ve had one experience putting Linux on Apple: a 2015 MacBook Pro. Linux could not handle the machine’s hardware-enabled switching from the onboard Intel video to the discrete GPU. One or the other had to be disabled during the boot process before the kernel loaded by using Grub to emit a magic string of bytes. Once booted, fan control was nonexistent – all max all the time. After the first kernel update the machine did not boot and I put OS X back on because for a machine intended for casual use there was no reason not to.
(So, if someome wants to extend the useful lifetime of older hardware Apple no longer supports, I can see installing Linux if it turns out not to break every other update. Otherwise, not.)
Probably neither. It’s okay to be uninformed and make mistakes without knee jerk reaction screeching in this world. I’m sure once Phoronix performs tests themselves or has an influx of confirmation, they’ll make another update.
There source is that one post on stack exchange who isn’t the source, who’s source is a single page on a web site saying you can’t but they never tried but you still can’t.
Its referring to the encryption keys I believe. Stuff like the hard drive cannot be replaced without losing all your data, unless you go to a repair tech and use transfer tools.
Don’t own a Mac and don’t keep up, just odd bits I have read.
There were claims simply replacing the display required the change to be “blessed” through a cloud authentication service, blocking third-party repairs:
One Reddit post claims Linux can still be installed on a external drive with the T2 disabled. Seems the internal SSD is still locked so OSes cannot be installed alongside macOS:
Ahh-- the issue is that the new T2 chip actually manages the storage, in the same way that your chipset usually manages it on standard PCs. I betcha Linux just doesn’t support the T2 yet.
FileVault/Encryption also encrypts the EFI partition when full disk encryption is set. What’s unclear is the behavior after you turn off all the protection with the T2 chip. With previous chips, the EFI partition is unlocked cause the disk is fully decrypted.
Okay, seems the issue is Linux literally can’t see the controller that handles the internal SSD. It’s no longer using a standard NVMe according to teardowns, so yes, the internal SSD actually has the T2 as it’s controller, directly communicating with the NAND that’s soldered onto the mainboard. (So no, you cannot upgrade your SSD anymore)
Yep, that was my guess earlier. Linux needs to support that T2 controller. Question is whether Apple plays ball or they need to reverse-engineer it, in which case it could be awhile.
Same deal with the iMac Pro. With T1 and T2, it’s not NVMe, it’s bare NAND and a proprietary controller. Though arguably it was a proprietary SSD in modified NVMe form factor in 2015, but at least Linux can see that Samsung controller, even though it was “proprietary.”
The 2017 MBP works and Linux can see the internal SSD, but T2 is invisible to Linux.
Do you remember when the PowerMac G5 was released, they said it would take a supercomputer 149 trillion years to defeat AES? That was how the world was introduced to FileVault.
Mine was that it isn’t “proprietary encryption” - it is industry standard AES. Same stuff used in millions of IPSEC connections the world over, other on disk encryption setups, etc.
There was a compatibility issue with the encryption when High Sierra got introduced, but then I quickly realized that can happen with any form of encryption, as implementation can cause these problems, not the actual crypto itself.
So yeah, I wasn’t gonna explain myself and look dumb. I originally had the point that Apple’s encryption was the root of the problem, but it’s not the crypto, it’s the implementation.
Now that we know Linux can’t even see the T2 controller, that rules out filesystem/full disk encryption cause people have been able to install other OSes on T1 just fine.
