Go 7 bootloop - Page 5

gleboss · Yesterday, 10:09 AM

Quote:

And autoupdate? Still 11%

Yes

Quote:

This is a normal Go7, right?

Yes

I've got the firmware here - http://data.onyx-international.cn/ap...t%22:%22%22%7D

It bothers me that it started out of the blue and the battery definitely couldn't drain from 50% to 0% in a day. I'm wondering if it could be a hardware problem after all.

gleboss · Yesterday, 10:20 AM

The battery itself looks fine...

Code:

# cat /sys/class/power_supply/battery/voltage_now
4413393
# cat /sys/class/power_supply/battery/capacity
100
# cat /sys/class/power_supply/battery/status
Charging

It looks like bootloop started out of the blue at some point, which led to battery drain, but why did it start at all if the book was in sleep mode?

Renate · Yesterday, 10:42 AM

The next time you get an 11% zip up /cache and post it. The log might be there.

Do that in custom recovery while it's still stalled.

gleboss · Yesterday, 10:45 AM

This might be not so easy, as the device disconnects from PC when it stucks on 11%

gleboss · Yesterday, 10:54 AM

In adb shell I see the cache folder is empty

gleboss · Yesterday, 01:54 PM

Tried new custom recovery and got the same "11% issue"

gleboss · Yesterday, 03:04 PM

Got smth interesting with the new recovery

Renate · Yesterday, 03:32 PM

You know, it could be a hardware error.

Besides, this thing should work without doing an update (if I ever got super correct).

Do you have an sha256 utility?
Your product.img should be:

Code:

630,923,264
7489c4865615685d 3f5adc031832ac67 524ccd68a4c21f25 f4a3e8a28c9c5f97

Code:

sha256 product.img
edl /w /psuper /s4096 product.img
edl /r /psuper /s4096 /c1232272 check.img
dir check.img
sha256 check.img
edl /i /v

Give me the 352 hex pairs if /i /v worked.

gleboss · Yesterday, 03:41 PM

Quote:

Besides, this thing should work without doing an update

Nope..it shows boot loop as always..

Hashes and sizes looks the same:

Code:

> Get-FileHash .\output\product.img -Algorithm SHA256

Algorithm       Hash                                                          
---------       ----                                                                
SHA256          7489C4865615685D3F5ADC031832AC67524CCD68A4C21F25F4A3E8A28C9C5F97

> dir check.img

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a----        17.03.2026     22:37      630923264 check.img

> Get-FileHash check.img -Algorithm SHA256

Algorithm       Hash                                                                
---------       ----                                                                 
SHA256          7489C4865615685D3F5ADC031832AC67524CCD68A4C21F25F4A3E8A28C9C5F97

> .\edl.exe /i /v
Found EDL 9008, configuring...
<log value="INFO: Calling handler for configure" />
<log value="INFO: Storage type set to value eMMC" />
<response value="ACK" MemoryName="eMMC" MinVersionSupported="1" Version="1" MaxPayloadSizeToTargetInBytes="65536" MaxPayloadSizeToTargetInBytesSupported="1048576" MaxXMLSizeInBytes="4096" DateTime="Aug 21 2020 - 09:02:30" />
Ok
Requesting info on LUN 0...
<log value="INFO: Calling handler for getstorageinfo" />
<log value="INFO: Device Total Logical Blocks: 0x747c000" />
<log value="INFO: Device Block Size in Bytes: 0x200" />
<log value="INFO: Device Total Physical Partitions: 0x4" />
<log value="INFO: Device Manufacturer ID: 0xd6" />
<log value="INFO: Device Serial Number: 0xea8ac3d" />
<log value="INFO: {&quot;storage_info&quot;: {&quot;total_blocks&quot;:122142720, &quot;block_size&quot;:512, &quot;page_size&quot;:512, &quot;num_physical&quot;:4, &quot;manufacturer_id&quot;:214, &quot;serial_num&quot;:245935165, &quot;fw_version&quot;:&quot;1&quot;,&quot;mem_type&quot;:&quot;eMMC&quot;,&quot;prod_name&quot;:&quot;C21E00&quot;}}" />
<log value="INFO: eMMC Extended CSD Revision: 0x8" />
<log value="INFO: eMMC Firmware Version: 0x1" />
<log value="INFO: eMMC_RAW_DATA[0:177]00000000000000000000000000000000390100106B02000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002000002000000000010000000000000000000000000000000000000000000000000000B50900070001000000151F20001E00000000000000" />
<log value="INFO: eMMC_RAW_DATA[178:355]003800000000010000000000000008000200571F0A0B00000000000808080808080100C047070E14140808100102010820000709F7550200000000000000016400000000000B0B000600000001000000000000000000010801010101000000000000000000000000000000000000000000000000000000000000000000000000001F010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000" />
<log value="INFO: eMMC_RAW_DATA[356:532]0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001FFFFFFFF000001032905000301203C0101010000000000000043002DD632014FD0FF03598FEFFFFFFF0000408A" />
<response value="ACK" rawmode="false" />
Ok

Renate · Yesterday, 03:50 PM

It says that your flash is fine:

Code:

csdview csd.bin
Manufacturer: 0xd6
Version:      5.1
User size:    122142720 blocks, 58.2 GB
Boot size:    8192 blocks, 4.0 MB
RPMB size:    8192 blocks, 4.0 MB
Cache size:   1536 blocks
Life used:    A: <10%, B: <10%
End of life:  Normal

You can try doing an update then reading the check.img to see if it matches.

gleboss · Yesterday, 04:11 PM

Yes, it matches. I also checked the other partitions - system, system_ext, odm, vendor - everything is fine.

Also, I have a dump of my super:

Code:

> lpdumps.exe .\super_current.img
Slot 0:
Metadata version: 10.2
Metadata size: 796 bytes
Metadata max size: 65536 bytes
Metadata slot count: 3
Header flags: virtual_ab_device
Partition table:
------------------------
  Name: odm_a
  Group: qti_dynamic_partitions_a
  Attributes: readonly
  Extents:
    0 .. 2047 linear super 2048
------------------------
  Name: product_a
  Group: qti_dynamic_partitions_a
  Attributes: readonly
  Extents:
    0 .. 1232271 linear super 4096
------------------------
  Name: system_a
  Group: qti_dynamic_partitions_a
  Attributes: readonly
  Extents:
    0 .. 6059575 linear super 1236368
------------------------
  Name: system_ext_a
  Group: qti_dynamic_partitions_a
  Attributes: readonly
  Extents:
    0 .. 943847 linear super 7295944
------------------------
  Name: vendor_a
  Group: qti_dynamic_partitions_a
  Attributes: readonly
  Extents:
    0 .. 1163519 linear super 8239792
------------------------
Super partition layout:
------------------------
super: 2048 .. 4096: odm_a (2048 sectors)
super: 4096 .. 1236368: product_a (1232272 sectors)
super: 1236368 .. 7295944: system_a (6059576 sectors)
super: 7295944 .. 8239792: system_ext_a (943848 sectors)
super: 8239792 .. 9403312: vendor_a (1163520 sectors)
------------------------
Block device table:
------------------------
  Partition name: super
  First sector: 2048
  Size: 6442450944 bytes
  Flags: none
------------------------
Group table:
------------------------
  Name: default
  Maximum size: 0 bytes
  Flags: none
------------------------
  Name: qti_dynamic_partitions_a
  Maximum size: 6438256640 bytes
  Flags: none
------------------------

What if the problem is with metadata?

gleboss · Yesterday, 04:25 PM

I tried to flash empty metadata:

Code:

> fsutil file createnew metadata_empty.img 16777216
> .\edl.exe /w /pmetadata .\metadata_empty.img

Hash mismatch problem is gone, but the update process is stuck without any errors and the device has been disconnected from PC.

Renate · Today, 01:07 AM

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.

Yesterday, 03:04 PM	#67
gleboss Enthusiast Posts: 39 Karma: 10 Join Date: Mar 2026 Device: Onyx Boox Go 7	Got smth interesting with the new recovery Attached Thumbnails

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Troubleshooting PW5 bootloop	Mars95	Amazon Kindle	5	08-19-2023 11:40 AM
PW5 PW stuck in a bootloop.........	kdusr	Kindle Developer's Corner	6	11-26-2022 01:58 AM
PRS-T1 bootloop	charmees	Sony Reader	9	11-23-2018 03:13 PM
PRS-T1 bootloop	klaasvaak42	Sony Reader	0	10-20-2018 04:45 AM
My Kobo goes into a bootloop!	alabrand	Kobo Reader	4	06-03-2016 02:44 PM

Yesterday, 10:20 AM	#62
gleboss Enthusiast Posts: 39 Karma: 10 Join Date: Mar 2026 Device: Onyx Boox Go 7	The battery itself looks fine... Code: # cat /sys/class/power_supply/battery/voltage_now 4413393 # cat /sys/class/power_supply/battery/capacity 100 # cat /sys/class/power_supply/battery/status Charging It looks like bootloop started out of the blue at some point, which led to battery drain, but why did it start at all if the book was in sleep mode?

Yesterday, 10:42 AM	#63
Renate Onyx-maniac Posts: 4,352 Karma: 20878213 Join Date: Feb 2012 Location: Germany Device: Nook NST, Glow2, 3, 4, '21, Kobo Aura2, Poke3, Poke5, Go6	The next time you get an 11% zip up /cache and post it. The log might be there. Do that in custom recovery while it's still stalled.

Yesterday, 10:45 AM	#64
gleboss Enthusiast Posts: 39 Karma: 10 Join Date: Mar 2026 Device: Onyx Boox Go 7	This might be not so easy, as the device disconnects from PC when it stucks on 11%

Yesterday, 10:54 AM	#65
gleboss Enthusiast Posts: 39 Karma: 10 Join Date: Mar 2026 Device: Onyx Boox Go 7	In adb shell I see the cache folder is empty

Yesterday, 01:54 PM	#66
gleboss Enthusiast Posts: 39 Karma: 10 Join Date: Mar 2026 Device: Onyx Boox Go 7	Tried new custom recovery and got the same "11% issue"

Yesterday, 03:32 PM	#68
Renate Onyx-maniac Posts: 4,352 Karma: 20878213 Join Date: Feb 2012 Location: Germany Device: Nook NST, Glow2, 3, 4, '21, Kobo Aura2, Poke3, Poke5, Go6	You know, it could be a hardware error. Besides, this thing should work without doing an update (if I ever got super correct). Do you have an sha256 utility? Your product.img should be: Code: 630,923,264 7489c4865615685d 3f5adc031832ac67 524ccd68a4c21f25 f4a3e8a28c9c5f97 Code: sha256 product.img edl /w /psuper /s4096 product.img edl /r /psuper /s4096 /c1232272 check.img dir check.img sha256 check.img edl /i /v Give me the 352 hex pairs if /i /v worked.

Yesterday, 03:50 PM	#70
Renate Onyx-maniac Posts: 4,352 Karma: 20878213 Join Date: Feb 2012 Location: Germany Device: Nook NST, Glow2, 3, 4, '21, Kobo Aura2, Poke3, Poke5, Go6	It says that your flash is fine: Code: csdview csd.bin Manufacturer: 0xd6 Version: 5.1 User size: 122142720 blocks, 58.2 GB Boot size: 8192 blocks, 4.0 MB RPMB size: 8192 blocks, 4.0 MB Cache size: 1536 blocks Life used: A: <10%, B: <10% End of life: Normal You can try doing an update then reading the check.img to see if it matches.

Yesterday, 04:25 PM	#72
gleboss Enthusiast Posts: 39 Karma: 10 Join Date: Mar 2026 Device: Onyx Boox Go 7	I tried to flash empty metadata: Code: > fsutil file createnew metadata_empty.img 16777216 > .\edl.exe /w /pmetadata .\metadata_empty.img Hash mismatch problem is gone, but the update process is stuck without any errors and the device has been disconnected from PC.

Today, 01:07 AM	#73
Renate Onyx-maniac Posts: 4,352 Karma: 20878213 Join Date: Feb 2012 Location: Germany Device: Nook NST, Glow2, 3, 4, '21, Kobo Aura2, Poke3, Poke5, Go6	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.

Advert

Advert