[General Questions and Answers] tom353:
It’s been a while (life happens...), but I haven’t given up on this!

I couldn’t get MTKClient to run on MacOSX, but I eventually got my hands on an old PC and used the liveDVD.

So, I did what you suggested. Backup up seccfg, unlocked bootloader with MTKClient, switched slots with fastboot, then restored seccfg.

Unfortunately, the device is still stuck in the same bootloop. Then after maybe 5 tries it goes into either fastboot, or that “Can’t load Android system. Your data may be corrupt.” screen from my first post.

Also, it switches back to slot A during that bootloop.

I could verify that after a ./fastboot reboot (into fastboot again) , the current-slot was indeed changed to B.

$ ./fastboot getvar current-slot

current-slot: a

Finished. Total time: 0.003s

$ ./fastboot --set-active=b

Setting current slot to 'b' OKAY [ 0.011s]

Finished. Total time: 0.014s

$ ./fastboot getvar current-slot

current-slot: a

Finished. Total time: 0.003s

$ ./fastboot set_active b

Setting current slot to 'b' OKAY [ 0.008s]

Finished. Total time: 0.011s

$ ./fastboot getvar current-slot

current-slot: a

Finished. Total time: 0.003s

$ ./fastboot reboot

Rebooting OKAY [ 0.003s]

Finished. Total time: 0.003s

$ ./fastboot getvar current-slot

current-slot: b

Finished. Total time: 0.003s

During the bootloop , I also diverted it into fastboot to verify, after 2 or 3 boot attempts, it was still on B. But later on it switched back to A.

Actually, I noticed that I could change the slot without unlocking the bootloader.

There are 2 ways to access fastboot on that device. One way is from within recovery mode, which I had been using initially, and in this fastboot I’m getting this message “set_active command is not allowed on locked devices”. But the other way is to access fastboot from the first menu, and that fastboot lets me use set_active.

This restriction that applies to one fastboot and not the other made me wonder whether the “OKAY” message actually did the job, but the different responses from getvar current-slot seem to confirm that.

Anyway, the short conclusion is that switching slots didn’t make the device to boot, and it sets itself back to slot A after trying to boot on B.

Another observation I made is that I’m not sure MTKClient effectively unlocked my device. It reported that it unlocked it, but then when I used it the second time to restore seccfg, it said “Device is protected”.

[09:56:23]: Loading payload from mt6765_payload.bin, 0x264 bytes

[09:56:23]: Kamakiri / DA Run

[09:56:23]: Trying kamakiri2..

[09:56:23]: Done sending payload...

[09:56:24]: Successfully sent payload: /opt/mtkclient/mtkclient/payloads/mt6765_payload.bin

[09:56:24]: Device is protected.

[09:56:24]: Device is in BROM mode. Trying to dump preloader.

[09:56:58]: Bootloader: unlock

[10:05:07]: Loading payload from mt6765_payload.bin, 0x264 bytes

[10:05:07]: Kamakiri / DA Run

[10:05:07]: Trying kamakiri2..

[10:05:07]: Done sending payload...

[10:05:07]: Successfully sent paylad: /opt/mtkclient/mtkclient/payloads/mt6765_payload.bin

[10:05:07]: Device is protected.

[10:05:07]: Device is in BROM mode. Trying to dump preloader.

[10:07:25]: test

[10:07:35]: write done!

I also went to see what fastboot was reporting after unlocking with MTKClient:

$ ./fastboot getvar unlocked

unlocked: no

Finished. Total time: 0.003s

However, that doesn’t necessarily matters, as I didn’t need to unlock it to switch slots.

Now, is there anything else I could try?

I was thinking of retrying to ADB sideload the stock OTA while the device is “maybe unlocked”.

I mean, by the look of it, it’s still locked, but I have limited trust in what my 2 inconsistent fastboot report.

So, assuming it is unlocked, is it safe to try ADB sideload while unlocked, or could this cause data loss?