Bootloop after fastboot flash vbmeta

Since you tried to reflash to stock you probably don’t need a A.0128 vbmeta.img anymore, right?! :thinking:

What errors did you get when running the flash_fp4_factory.command script?
If you didn’t get any have you tried changing the slot fastboot --set-active=a? That part of the script is still broken and won’t execute if you don’t have fastboot in your $PATH (if you are on Linux, no idea how that works on Windows :man_shrugging:)… :roll_eyes:

1 Like

I am also having this problem.
I would like to install Magisk 25.2 on my FP4. Since the version newer than A142 for FP4 no longer provide boot.img on kernel source website, I patiently waited for A170 factory image appear on the offline download page.
So I downloaded the zip but flashed stock A142 boot.img back before letting the phone update itself to A170. Then I extracted the boot.img from to let Magisk patch it. The patched boot does not work. The system UI crashes constantly. I tried again confirming I’m not using the old boot.img. Same thing.
So I looked at the install guide on Magisk github. It suggests in addition to flashing patched boot.img, vbmeta needs to be flashed too with this prompt. So I extracted vbmeta from Now I’m having bootloop suggesting factory reset.
I tried flashing unpatched boot and vbmeta. Does not work. What could I do to save it?

Welcome to the community :wave:

So am I understanding you correctly, that you were running Magisk already? If that’s the case, why didn’t you update using the Magisk app? :thinking:
Why did you flash the A.142 boot.img? Were you on that version before you updated?

(Optional) If your device has a separate vbmeta partition, you can patch the vbmeta partition with command:

Entirely optional and you absolutely don’t need to use that for the FP4.

Before we try to get this fixed, could you reboot into recovery and check the third line from the top for the version in your current slot (the last four characters are enough) and the output of …

fastboot getvar current-slot getvar slot-unbootable:a getvar slot-unbootable:b

… might be helpful as well.

Because I installed Magisk by patching the boot.img, and the system updater would not let me update with that. Some integrity verification I guess?
The Magisk did not receive update, so no need to update it. The only way to install available in the app is patching boot.img.

The output is:

current-slot: a
slot-unbootable:a: no
slot-unbootable:b: no
Finished. Total time: 0.008s

You can just restore the image in the app and flash it to the other slot:

Ok, so none of your slots failed, that’s something. Please check the version in recovery as well, so we are sure you are actually running A.170 :pray:

The version is 11/RKQ1.210503.001/FP4D

That’s A.163. Could you try changing the slot fastboot set_active=b? :thinking:

One step missing in the steps above:

Before you do any of that, disable ALL magisk modules you have!

I didn’t an d that caused bootloops on magisk-patched images!

That’s a good point, if you plan on booting the phone without a patched boot.img.
If you just perform an OTA update (and don’t reboot in between), that’s not necessary.

Oh darn it. I checked again on the offline install zip download page. It clearly writes A170 but the downloaded item ends with FP4D.

I tried again switching to slot b. Same prompt suggesting factory reset : (

Could you check the version in recovery again, so we have the complete picture :pray:

I’ve noticed the wrong naming before as well and thought they just named it wrong, but I just checked and the hashes match, which makes sense, because both A.163 and A.170 share the same URL :man_facepalming:

Here’s the proper link to A.170.

Oh so now I’m on slot B, and in the recovery the version ends with FP40

Interesting, I would have expected A.170 in that slot :thinking:
Something doesn’t add up.

Anyways, switch back to a and try booting the A.170 stock boot.img from the .zip I linked above and let’s see what that gets us …

Same prompt demanding reset nao

I’m not 100% sure if the version information in the recovery gets supplied by the boot partition or if it shows the internal versioning, that might explain the mismatch :thinking:

Try it again after flashing that A.170 vbmeta.img, if the update actually went through, and you are on A.170, that’s still the wrong one as well.

I tried twice flashing A.170 boot & vbmeta before reboot. Still the same prompt.
I guess the auto update worked because I remember the phone loaded and I checked the system information in settings. However the system UI would crash once before loading probably because I’m applying A.163 boot on a A.170 system…?
If that’s the case the act of flashing A.163 vbmeta on A.170 probably the step that broke it…?

Ok, so you checked the settings after the update and you were on A.170?
And after that you flashed the A.163 images, right?

I’m not sure, maybe the --disable-verity --disable-verification part in the Magisk instructions changed a flag that’s keeping the device from booting correctly :thinking:

I’ve uploaded a (confirmed working) A.170 Magisk boot.img, maybe try that as well, to rule out problems caused by Magisk modules.

Well that did not work still. Is resetting the only way? Maybe flashing twrp to salvage my data first?

Without exactly knowing what ultimately broke your system, a factory reset seems like the logical next step, yeah :see_no_evil:

TWRP isn’t useful in your case, it can’t access the encrypted userdata.

1 Like

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.