Boox Note Air 2 Plus v4 update - boot stuck

[Renate]

What did you try to sideload?
Which files did it have?
Normally it checks the SHA both before and after on each partition.

Recovery uses a lot less stuff than the normal system, but I'm still not clear on how much it needs.
And that changes all the time too.

You can't do a simple write for super, but recovery doesn't need super.
The other ones can just be written if you have a good copy,

[ptrpolar]

I tryed to sideload (at the beginning, when the tablet went to recovery with button) the update.zip converted from the update.upx.
The operation stopped at 47% returning the error I reported on my first post.

[Renate]

An incremental update is very precarious.
Even full updates are bad enough.
When you use my recovery for updates you get a full log so you can see why it failed.
"Failed at 47%" tells me nothing.
If you try to do an incremental update after installing Magisk it will fail.

So to make things clear. You used only one update but you tried using two methods?
How big was this update? What's the link?
Why do you think that you extracted the files correctly?

[ptrpolar]

In summary:
- I downloaded the firmware from this link:

http://en-data.onyx-international.cn/api/firmware/update?where={"buildNumber":0,"buildType":"user"," deviceMAC":"","lang":"en_US","model":"NoteAir2P"," submodel":"","fingerprint":""}

- Obtained the file update.upx, I decrypted it with this tool that gave me update.zip:

https://github.com/Hagb/decryptBooxUpdateUpx

- Then, I tryed to sideload it (when I was able to enter in the tablet recovery with button) - adb sideload update.zip. It returned the error:

"Error applying update: 7 (ErrorCode: : kInstallDeviceOpenError)"
"E:Error in /sedeload/package.zip (status1)

- Then, I extracted the images from payload.bin (contained in the update.zip) with this tool:

https://github.com/ssut/payload-dumper-go

It extracted:

abl.mg
boot.img
dtbo.img
modem.img
product.img
recovery.img
system.img
system_ext.img
vbmeta.img
vbmeta_system.img
vendor.img
xbl.img

Then, with edl (edl /u /w /pxxx xxx.img), I flashed these images, both on slot a and b: abl, boot, dtbo, recovery, vbmeta, vbmeta_system, xbl.

If you try to do an incremental update after installing Magisk it will fail.

I didn't installed Magisk and I've never tryed rooting.

[Renate]

The recovery I made for you was for the NoteAir2 not the NoteAir2P.
I don't know if there are any real differences.

We're shooting in the dark here.
Was this already on Onyx/NoteAir2P/NoteAir2P:11/2025-04-01_20-27_v4.0-rel_6d15a71551/49339:user/release-keys
and working before you ran into trouble?
Writing a new vb_system and not writing system will cause problems.
But all this doesn't explain why you can't get the stock recovery to work.

There's still a lot of partitions left that are never distributed in updates.
You can try comparing the _a and _b versions of things.
But that gets complicated.
The important stuff rarely fills the partition.
So if you compare two partitions and they read different it could be that the important parts are the same and the fluff and dust after is different.

You can pull the _a and the _b of something.
If they check out as they same, they are the same.
If they are different you have to see if the differences are past the good stuff.

edl /u /r /pwhatever_a a.img
edl /u /r /pwhatever_b b.img
fc /b a.img b.img | more

If the first line says "3245" things are different.
If the first line says "123000" (higher number ending in 3 zeroes) they probably are the same.

[Renate]

Actually, I'm forgetting my own software.
For both Android images (boot, recovery) and ELF images (xbl, abl, rpm, cmnlib...) the /t flag only loads the "truncated" image.
So you can:

edl /u /r /t /pwhatever_a a.img
edl /u /r /t /pwhatever_b b.img
fc /b a.img b.img | more

This will generate files only as big as the "real" content.
So when you compare the files you won't be comparing the dust bunnies at the end of the partitions.

[ptrpolar]

You can try comparing the _a and _b versions of things.

Done: FC returned no differences between the following images _a and _b:
- abl
- boot
- dtbo
- recovery
- vbmeta
- vbmeta_system
- xbl

[Renate]

I don't know.
xbl, abl are certainly needed for recovery.
tz, cmnlib, cmnlib64 are needed for security on the normal system.
rpm is needed for charging.
is hyp needed? I don't know.

If you flashed something to both slots, of course they should be the same.
But are they the right ones?
Did you compare them to the ones you extracted out of update.zip

[ptrpolar]

Did you compare them to the ones you extracted out of update.zip

Yes, they are the same.

I think the problem with slot b unbootable could be the solution

[Renate]

Yes, but you haven't shown any difference between a and b.
Did you try setting active slot in fastboot?

If this were mine I'd open it up and find the UART.
That will give you some information on bootup.

Which slot is active is part of the OEM code.
It is reflected in the GPT type GUIDs.
I can't say if the slot is driven by that or a secret bit somewhere.

It should be possible to write some code to swap the a and b.
But if you screwed things up it would just make life that much harder.

[ptrpolar]

Did you try setting active slot in fastboot?

I can't do that.

fastboot getvar current-slot
current-slot: b

fastboot --set-active=a
Setting current slot to 'a' FAILED (remote: 'unknown command')
fastboot: error: Command failed

At the moment the current slot B is unbootable:

fastboot getvar all

(bootloader) has-slot:modem:yes
(bootloader) has-slot:system:no
(bootloader) current-slot:b
(bootloader) has-slot:boot:yes
(bootloader) slot-retry-count:b:0
(bootloader) slot-unbootable:b:yes
(bootloader) slot-successful:b:no
(bootloader) slot-retry-count:a:2
(bootloader) slot-unbootable:a:no
(bootloader) slot-successful:a:no
(bootloader) slot-count:2
(bootloader) secure:no
(bootloader) serialno:369B908B
(bootloader) product:bengal
(bootloader) snapshot-update-status:none
(bootloader) is-userspace:no
(bootloader) max-download-size:804268032
(bootloader) kernel:uefi

[ptrpolar]

If this were mine I'd open it up and find the UART.
That will give you some information on bootup.

I don't understand what you mean

[Renate]

There is an internal console output over an electrical interface that says why it's failing.

[ptrpolar]

Do you think a reset like "fastboot -w" could be useful? I know that in this case I'll lose my data, but could the tablet work?

[Renate]

Recovery doesn't even mount userdata so that's not what is stopping recovery.
Bad userdata can stop the normal system though.
Normally recovery is easier to get working because it doesn't use anything in super or the Android subsystem.
It's possible that there is a problem with the custom recovery that I gave you, but the stock one should work.
Are you sure that your copy of stock recovery is good.
And you have been flashing misc-recovery and misc-empty?