You can't wipe the metadata.
We've seen that it bombs if the directory structure isn't there.
The last one I gave you just had the snapshots removed.
Code:
Partition New Count Operations
-------------- ------ ----- ----------------------------------------
abl 156 k 1 REPLACE_XZ[1]
boot 96.0 M 48 REPLACE[2], REPLACE_XZ[26], REPLACE_BZ[20]
dtbo 8.00 M 4 REPLACE_XZ[1], REPLACE_BZ[3]
modem 59.2 M 30 REPLACE_XZ[30]
odm 1.00 M 1 REPLACE_XZ[1]
product 602 M 301 REPLACE[11], REPLACE_XZ[282], REPLACE_BZ[8]
recovery 96.0 M 48 REPLACE[2], REPLACE_XZ[30], REPLACE_BZ[16]
system 2.89 G 1480 REPLACE[78], REPLACE_XZ[1382], REPLACE_BZ[20]
system_ext 461 M 231 REPLACE[2], REPLACE_XZ[225], REPLACE_BZ[4]
vbmeta 8.00 k 1 REPLACE_XZ[1]
vbmeta_system 4.00 k 1 REPLACE_XZ[1]
vendor 568 M 285 REPLACE[1], REPLACE_XZ[282], REPLACE_BZ[2]
xbl 3.22 M 2 REPLACE_XZ[2]
You need 385 operations to finish with product.
The error is on operation 364.
Therefore the hash that they are speaking of is not the final partition hash.
It's an operation hash, but it could be the source or the data hash.
That this is an unlikely error is indicated by the fact that it's not handled correctly.
Currently this is the only update for the Go7.
If you have a link for an earlier update we could try that.
So either the update is corrupt or the recovery code expanding the update is corrupt or a one-in-a-billion hardware error.
Considering that we tried this first with an older custom recovery built on an older recovery that might rule some things out.
Also, my autoupdate is not directly involved in any of this. Yeah, it starts things but it's all up to the update_engine_sideload to do it.