| 18 Aug 2021 |
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 |
samueldr | Andreas Schrägle: "just" flash through that if you have the signed programmer, signed by the an accepted authority which would be the OEM, here google | 20:48:41 |
danielrf | But besides that I believe it should be safe | 20:48:48 |
samueldr | and google's, I think for all devices except nexus 7 (2013) haven't been published | 20:49:13 |
samueldr | not sure about other nexus devices, but pretty sure it wasn't for anything pixel | 20:49:33 |
ajs124 | In reply to @withoutwithin:matrix.org is it a bad idea to distribute a robotnix build across multiple machines? I do that, works fine. But what danielrf says does apply. | 21:03:05 |
ajs124 | In reply to @samueldr:matrix.org Andreas Schrägle: "just" flash through that if you have the signed programmer, signed by the an accepted authority which would be the OEM, here google I didn't need that for my moto x4, back in the day | 22:04:18 |
samueldr | what tool did you use to reflash? | 22:04:51 |
samueldr | though motorola is different | 22:05:11 |
samueldr | they have the "blankflash" thing | 22:05:18 |
samueldr | which I'm not sure how it is implemented | 22:05:31 |
samueldr | whether it's like oneplus, where the programmer is part of the tool you use to unbrick, or if it's another distinct protocol | 22:05:48 |
ajs124 | some windows thing, but there's also something by linaro. qms? something like that. | 22:25:15 |
samueldr | I never had a bricked motorola to blankflash so I can't say for sure | 22:28:22 |
samueldr | I'm giving it 50/50 that the programmer is part of the tool :) | 22:28:31 |