smbarber

Slight correction: we use btrfs for the disk image backing the user's crostini state only. The rest of Chrome OS, and the crostini VM rootfs, still use ext4.

On the Pixel C debug accessory mode is gated by the hardware write protect "screw" (front camera flex cable). Enabling it requires opening up the device to the point you could attach probes and rewrite SPI flash anyway.

No JTAG on the Pixel C either, just UARTs and SPI: https://chromium.googlesource.com/chromiumos/platform/ec/+/m...

The failure modes are completely different. The MacBook went overcurrent when a bad cable told an attached phone it could draw more current than it should. Detecting overcurrent due to a badly behaved device or a short in the cable is fairly common.

The cable attached to the Chromebook was totally miswired and flipped Vbus and ground, supplying -5V where 5V was expected. As the article said, nothing is really designed to handle this kind of failure because it should be blatantly obvious to the cable manufacturer if there were any sort of quality control.

Since NayuOS is still based on Chromium OS you should only need dev mode enabled to run it. It'll boot the same way that Chromium OS does. Legacy boot is only necessary for a traditional Linux distro that isn't using the Chrome OS format for kernel images.

For the record, the write protect is just a screw on Chrome OS devices and doesn't need to be desoldered.

This used to be true; freon came in 2015 and eliminated the X server on most Chrome OS devices.

http://tech.slashdot.org/story/15/03/09/0220205/google-intro...