[mariocord]

Originally Posted by Renate

As it says in https://www.temblast.com/ref/onyxldr.htm, the Firehose loader is:
https://github.com/bkerler/Loaders/b...dr_patched.elf

The latest update is:

Model:  TabUltra (English)
Finger: Onyx/TabUltra/TabUltra:11/2026-06-30_11-25_4.2-rel_0630_b7cf3517a3/51518:user/release-keys
Link:   http://firmware-us.boox.com/6b7ec9b9bfc68ec1f871ab0c227f0c24/update.upx
Size:   1,866,926,032
MD5:    6b7ec9b9bfc68ec1f871ab0c227f0c24

Update: huge thanks, the loader worked perfectly! Got full Firehose access, dumped the GPT across all 6 LUNs, verified the boot chain (xbl_b, abl_b, boot_b, dtbo_b, vbmeta_b, modem_b, vbmeta_system_b, recovery_b) by re-flashing them from the official firmware you linked and confirming with MD5 that writes landed correctly. Active slot is confirmed as 'b' throughout.

Device still hangs at the boot logo after all that, so I dumped the 'super' partition (LUN 0, 4GB) to inspect it, and found the root cause: the logical partition metadata is corrupt.

```
AssertionError: Logical partition metadata has invalid geometry magic signature.
```

(using liblp/lpunpack in Python to parse it)

This lines up perfectly with the January OTA failing mid-flash while writing the dynamic partitions (system/vendor/product/system_ext), leaving 'super' with an invalid/corrupted metadata header. The kernel boots fine (hence the logo showing), but init can never mount the dynamic partitions, so it hangs on the splash forever.

I have all four raw partition images (system.img, vendor.img, product.img, system_ext.img) extracted from the full OTA payload.bin you linked earlier, ready to rebuild 'super' with lpmake.

Before I start guessing at lpmake parameters (metadata size, partition group name, slot count) and risk multiple write cycles, does anyone know the exact lpmake invocation used for the Tab Ultra (kamorta platform)? Specifically the dynamic partition group name (is it 'qti_dynamic_partitions' or something else for this platform?) and metadata-size/metadata-slots values. The 'super' partition itself is exactly 0x100000000 bytes (4GiB) per the GPT.

Thanks again for all the help so far — this has been a great troubleshooting session.