5 ms·

Installing a custom kernel is an official feature on these machines and won't void your warranty. I've never had the installer do anything crazy, nor does it s

Installing a custom kernel is an official feature on these machines and won't void your warranty. I've never had the installer do anything crazy, nor does it support any resize/deletion operations yet, so it's pretty unlikely that it'll wipe your data (it's much more likely to just fail to complete the installation properly). More likely is that if you boot Linux, a driver bug will cause data corruption. We've had some reports of filesystem issues, though as I said the kernel tree situation is haphazard right now, so we'll see if they still happen once we put together a tree with properly vetted patches :)

zozbot234 5y ago
The common feature with these embedded ARM chipsets is that a faulty kernel can very much hardbrick your machine. There's nothing like the amount of failsafes you get with ordinary PC-compatible hardware. I wouldn't want to rely on any promise that "installing a custom kernel won't void your warranty" - in practice, it very much will if you don't know what you're doing.
- my123 5y ago
  Same for x86 machines really, the number of UEFI firmwares that hard-bricked the machine if you dared deleting all NVRAM variables... (and many more other issues)
  - floatboth 5y ago
    That number is not that big, IIRC just a few specific laptops. I haven't heard of any desktop mainboards with that issue.
    - my123 5y ago
      I remember some Lenovo server boards being bricked by an UEFI variable storage snafu, which was painful to handle.
- marcan_42 5y ago
  You're assuming Apple's ARM chipsets are like other embedded ARM chipsets. They aren't. Things are much cleaner and quite well designed. Storage-wise, you can't brick the machine by wiping NVMe. You can always recover via DFU mode, which you can also use from another Linux machine by using idevicerestore (no need for macOS). This is very much unlike your typical Android phone, which is indeed a flimsy mess that will brick itself at the slightest touch of the wrong partition in eMMC. Hardware-wise, there's the usual "you can technically do ugly things with I/O pins", but in practice that's quite unlikely to cause damage. The lowest level, dangerous things are handled by SMC, not the main OS. We barely have to deal with any of that. And this is a thing on PCs too, just read your chipset's user manual and you'll find out the registers to flip random I/O pins. Firmware-wise, I do know of one way of causing damage to these machines that cannot be recovered by the user: wiping NOR Flash. This isn't because it'll make DFU unusable, but rather because it contains things like system identity information and calibration data that only Apple can put back properly. But again, this isn't much different on PCs; you can brick a PC by wiping the NOR Flash from your OS too. In fact there have been BIOSes so broken that you can brick them by doing a `rm -rf /`, which descends into efivars and the UEFI implementation crashes when it finds no EFI variables. In order to avoid the NOR Flash bricking risk, I do not intend to instantiate the NOR device in our device tree at all by default. I do not believe we need it for regular operation. Flash memories have specific unlock sequences for writes/erases, so there is practically zero risk that a crazy random bug (i.e. scribbling over random I/O memory) could trigger such an operation, and without the NOR driver bound, the code that actually knows how to cause damage will never run. For what it's worth, I have quite some experience not bricking people's machines, even when dealing with unofficial exploits/hacks/jailbreaks. To my knowledge, not a single user out of the probably >10m people running The Homebrew Channel / BootMii on their Wii, which I helped develop, has bricked their system due to a problem traceable to our software. Nintendo has a much worse track record :-) https://marcan.st/2011/01/safe-hacking/ https://marcan.st/2011/01/safe-hacking/
  - floatboth 5y ago
    > system identity information and calibration data that only Apple can put back properly Ha. This reminds me of a Motorola Linux phone I bricked as a kid by trying to write a package manager in C shell (lol) which inevitably led to rm -rf / being executed which wiped a unique per-device security partition required for the boot process. Why did Apple make the same choice of putting critical data onto an OS-writable flash chip? Chromebooks do it right – everything critical lives in the Security Chip's own on-chip flash, and the list of commands it would take from the host system is very limited by default (most things are only available to the debug cable).
rvz 5y ago
> More likely is that if you boot Linux, a driver bug will cause data corruption. We've had some reports of filesystem issues, though as I said the kernel tree situation is haphazard right now, so we'll see if they still happen once we put together a tree with properly vetted patches :) Well that is another notable risk isn't it? If something goes wrong on the filesystem level (since you admitted it) then the worst case is that the OS and your important files become corrupted some how and it is back to recovery once again, if not then they will use Apple Configurator which requires another Mac. Regardless, I would most certainly use another machine to test this, hence why I said 'use at your own risk', especially when the installation script is pre-alpha. What is wrong with such a disclaimer?
- zamadatix 5y ago
  Do you really care if Linux corrupts its apfs container on machine 2 instead of machine 1? Just don't go mounting your macOS apfs container and it's no different. Regardless I think most of the problem was with defaulting to fear mongering, particularly at the warranty, rather than gaining an understanding of what the risks are before making recommending action to avoid said risks.
  - rvz 5y ago
    How is it fear-mongering to say 'Use at your own risk' for installing an OS that is not fully supported and even the installation script is in pre-alpha? Fine for those who have a spare M1 machine but the added risk comes when it is their only machine with important work and files on it. Do you want to be liable when someone tries this script out and somehow ends up losing their important work because of those recently admitted 'filesystem issues' on the only machine they have? That is my point and why I said: "I would most certainly use another machine to test this" I don't see lots of general users racing to install this right now, since they probably know that it is still incomplete with lots of bugs and is still unusable. Unless you want to install it right now on your work machine with important files perhaps? If not then wait.
- marcan_42 5y ago
  You can DFU these machines from Linux with idevicerestore, no need for Apple Configurator.

zozbot234 5y ago

The common feature with these embedded ARM chipsets is that a faulty kernel can very much hardbrick your machine. There's nothing like the amount of failsafes you get with ordinary PC-compatible hardware. I wouldn't want to rely on any promise that "installing a custom kernel won't void your warranty" - in practice, it very much will if you don't know what you're doing.

my123 5y ago
Same for x86 machines really, the number of UEFI firmwares that hard-bricked the machine if you dared deleting all NVRAM variables... (and many more other issues)
- floatboth 5y ago
  That number is not that big, IIRC just a few specific laptops. I haven't heard of any desktop mainboards with that issue.
  - my123 5y ago
    I remember some Lenovo server boards being bricked by an UEFI variable storage snafu, which was painful to handle.
marcan_42 5y ago
You're assuming Apple's ARM chipsets are like other embedded ARM chipsets. They aren't. Things are much cleaner and quite well designed. Storage-wise, you can't brick the machine by wiping NVMe. You can always recover via DFU mode, which you can also use from another Linux machine by using idevicerestore (no need for macOS). This is very much unlike your typical Android phone, which is indeed a flimsy mess that will brick itself at the slightest touch of the wrong partition in eMMC. Hardware-wise, there's the usual "you can technically do ugly things with I/O pins", but in practice that's quite unlikely to cause damage. The lowest level, dangerous things are handled by SMC, not the main OS. We barely have to deal with any of that. And this is a thing on PCs too, just read your chipset's user manual and you'll find out the registers to flip random I/O pins. Firmware-wise, I do know of one way of causing damage to these machines that cannot be recovered by the user: wiping NOR Flash. This isn't because it'll make DFU unusable, but rather because it contains things like system identity information and calibration data that only Apple can put back properly. But again, this isn't much different on PCs; you can brick a PC by wiping the NOR Flash from your OS too. In fact there have been BIOSes so broken that you can brick them by doing a `rm -rf /`, which descends into efivars and the UEFI implementation crashes when it finds no EFI variables. In order to avoid the NOR Flash bricking risk, I do not intend to instantiate the NOR device in our device tree at all by default. I do not believe we need it for regular operation. Flash memories have specific unlock sequences for writes/erases, so there is practically zero risk that a crazy random bug (i.e. scribbling over random I/O memory) could trigger such an operation, and without the NOR driver bound, the code that actually knows how to cause damage will never run. For what it's worth, I have quite some experience not bricking people's machines, even when dealing with unofficial exploits/hacks/jailbreaks. To my knowledge, not a single user out of the probably >10m people running The Homebrew Channel / BootMii on their Wii, which I helped develop, has bricked their system due to a problem traceable to our software. Nintendo has a much worse track record :-) https://marcan.st/2011/01/safe-hacking/ https://marcan.st/2011/01/safe-hacking/
- floatboth 5y ago
  > system identity information and calibration data that only Apple can put back properly Ha. This reminds me of a Motorola Linux phone I bricked as a kid by trying to write a package manager in C shell (lol) which inevitably led to rm -rf / being executed which wiped a unique per-device security partition required for the boot process. Why did Apple make the same choice of putting critical data onto an OS-writable flash chip? Chromebooks do it right – everything critical lives in the Security Chip's own on-chip flash, and the list of commands it would take from the host system is very limited by default (most things are only available to the debug cable).

rvz 5y ago

> More likely is that if you boot Linux, a driver bug will cause data corruption. We've had some reports of filesystem issues, though as I said the kernel tree situation is haphazard right now, so we'll see if they still happen once we put together a tree with properly vetted patches :) Well that is another notable risk isn't it? If something goes wrong on the filesystem level (since you admitted it) then the worst case is that the OS and your important files become corrupted some how and it is back to recovery once again, if not then they will use Apple Configurator which requires another Mac. Regardless, I would most certainly use another machine to test this, hence why I said 'use at your own risk', especially when the installation script is pre-alpha. What is wrong with such a disclaimer?

zamadatix 5y ago
Do you really care if Linux corrupts its apfs container on machine 2 instead of machine 1? Just don't go mounting your macOS apfs container and it's no different. Regardless I think most of the problem was with defaulting to fear mongering, particularly at the warranty, rather than gaining an understanding of what the risks are before making recommending action to avoid said risks.
- rvz 5y ago
  How is it fear-mongering to say 'Use at your own risk' for installing an OS that is not fully supported and even the installation script is in pre-alpha? Fine for those who have a spare M1 machine but the added risk comes when it is their only machine with important work and files on it. Do you want to be liable when someone tries this script out and somehow ends up losing their important work because of those recently admitted 'filesystem issues' on the only machine they have? That is my point and why I said: "I would most certainly use another machine to test this" I don't see lots of general users racing to install this right now, since they probably know that it is still incomplete with lots of bugs and is still unusable. Unless you want to install it right now on your work machine with important files perhaps? If not then wait.
marcan_42 5y ago
You can DFU these machines from Linux with idevicerestore, no need for Apple Configurator.