| 18 Aug 2021 |
 Xe (xe/they) | would have to transfer from an esim to a psim though | 17:56:03 |
 hmenke | danielrf: We should maybe add to the installation docs that the user has to make sure they're flashing the correct device before running ./flash-all.sh. On the https://matrix.to/#/#grapheneos:grapheneos.org channel I heard that flashing the wrong image can brick the device. | 18:30:23 |
| hmenke | * danielrf: We should maybe add to the installation docs that the user has to make sure they're flashing the correct device before running ./flash-all.sh. On the #grapheneos:grapheneos.org channel I heard that flashing the wrong image can brick the device. | 18:30:32 |
 danielrf | Redacted or Malformed Event | 18:30:39 |
| danielrf | hmenke: Hmm I thought there were checks that prevented that | 18:32:31 |
| danielrf | ah, so, for instance, in image-crosshatch-2021.04.22.20.zip that would get fastboot updated, there's an android-info.txt that contains this: | 18:33:31 |
| danielrf | require partition-exists=product
require version-bootloader=b1c1-0.3-7065185
require version-baseband=g845-00166-210105-B-7062333
| 18:33:38 |
| danielrf | * require partition-exists=product
require version-bootloader=b1c1-0.3-7065185
require version-baseband=g845-00166-210105-B-7062333
| 18:34:01 |
| danielrf | * require board=crosshatch
require partition-exists=product
require version-bootloader=b1c1-0.3-7065185
require version-baseband=g845-00166-210105-B-7062333
| 18:34:10 |
| danielrf | and it does prevent running fastboot update against a non-crosshatch device | 18:34:59 |
| danielrf | but maybe you're right that flash-all.sh which flashes the bootloader and radio as well don't have similar checks | 18:35:30 |
| danielrf | Probably still a good idea to add a note anyway | 18:37:00 |
| Xe (xe/they) | when setting your own custom root of trust, is there a way to get rid of the custom OS warning? | 18:39:44 |
| danielrf | Nope, we can't change that. | 18:41:31 |
| danielrf | At least it's a "yellow" warning screen and not a "red" one :) https://source.android.com/security/verifiedboot/boot-flow#communicating-verified-boot-state-to-users | 18:41:43 |
| Xe (xe/they) | ah, fair | 18:42:14 |
 cde | hmenke: danielrf 1177: Check for product name before flashing factory image | https://review.calyxos.org/c/CalyxOS/device_common/+/1177 | 18:51:22 |
 samueldr | oof, with bootloader flashed to the wrong thing I guess that could brick a device | 18:58:27 |
| samueldr | though it's "out of band" that the flashing happens, not through the usual route IIRC for radio | 18:58:50 |
| samueldr | * though it's "out of band" that the flashing happens, not through the usual route IIRC for bootloader/radio | 18:58:56 |
| samueldr | so I wonder why it doesn't check for an appropriate one | 18:59:05 |
 ajs124 | if it's qualcomm, they normally have their recovery thing where it shows up as a serial device and you can just flash through that | 18:59:54 |
| cde | there are checks already in some cases preventing wrong bootloader flashing | 19:05:58 |
| cde | but sometimes it may not work, I don't know when exactly | 19:06:09 |
| cde | and it's nothing I'd want to find out the hard way :P | 19:06:17 |
| cde | but I have accidentally had a script flash the wrong bootloader to a device but the device rejected it | 19:06:30 |
| cde | at the same time, a user tried to flash our sunfish build to their bramble (it was just released, nobody supported it then) and managed to brick | 19:06:48 |
| Xe (xe/they) | is it a bad idea to distribute a robotnix build across multiple machines? | 20:45:24 |
| danielrf | Most of the AOSP build takes place in one giant derivation, so there's not a ton of benefit unfortunately. (chromium and kernel builds could take place on another machine, though, and save some time) | 20:47:29 |
| danielrf | The other gotcha would be if you're using the Nix sandbox exception to access your signing keys--then you'd have to ensure the final derivations which sign the build take place on a machine with the sandbox exception | 20:48:40 |
