Empty vbmeta is not disabled vbmeta

May 11, 2026 #android #avb #bootloader #flashing

“Flash an empty vbmeta to bypass Android verification.” That was the advice on a forum thread, from a user who’d successfully flashed a custom recovery on the same phone family. So I did it. And the device started bootlooping right after the splash screen.

The bootloader had been unlocked for years. verifiedbootstate=orange. AVB checks skipped at boot. An empty (all-zero) vbmeta.img should change nothing meaningful, right?

Wrong. And the reason matters.

The model I was operating with

verifiedbootstate=orange means the bootloader trusts whatever you flash. So I assumed: bootloader doesn’t care about vbmeta contents, init doesn’t care about vbmeta contents, all good.

This model is missing a layer. The bootloader trusts the boot image and lets init run. But init then has to set up the rest of the system — /system, /vendor, /product, /system_ext — and on a dynamic-partition device, those live as logical volumes inside super. Mounting them requires the dm-verity hash tree descriptors. Those descriptors live in vbmeta.

Zero out vbmeta and init has nothing to feed dm-verity. The mount fails. init panics, reboots. Welcome to your splash-screen bootloop.

The bootloader said “go ahead.” It was the kernel that refused.

The actual fix

You don’t want vbmeta gone. You want vbmeta saying “the descriptors are here, but please don’t enforce them.” That’s avbtool make_vbmeta_image --flags 3:

avbtool make_vbmeta_image \
  --flags 3 \
  --padding_size 4096 \
  --output disabled-vbmeta.img

Flag bit 0 is HASHTREE_DISABLED. Bit 1 is VERIFICATION_DISABLED. The output is still a structurally valid AVB blob — AVB0 magic, 256-byte header, no descriptors, no auth, no aux. init reads it, sees the disable flags, doesn’t try to wire up dm-verity, mounts everything as plain block devices. The device boots.

avbtool info_image on the result:

Header Block:             256 bytes
Authentication Block:     0 bytes
Auxiliary Block:          0 bytes
Algorithm:                NONE
Flags:                    3
Descriptors:
    (none)

That’s a meaningful object. Zeros are not.

What I should have caught earlier

I tried fastboot --disable-verity --disable-verification flash vbmeta vbmeta.img first, using the OEM’s signed vbmeta. Recent fastboot — 36.x — rejected it with Failed to find AVB_MAGIC at offset: 0, even though the magic was visibly at offset 0 in xxd. The new fastboot tries to parse the header structure to toggle flags in place, and chokes on the OEM’s non-standard auxiliary block layout.

The fix is obvious in hindsight: don’t rewrite the OEM blob, mint a fresh minimal one. Older fastboot (28.x–30.x) would have worked too, but that’s papering over the actual question, which is what does the vbmeta need to look like for this to work?

The 5-minute version

“Orange” bootloader does not disable dm-verity.
On Android 11+ with dynamic partitions, dm-verity setup needs metadata from vbmeta.
Zeroed vbmeta = no metadata = mount fails = bootloop.
A flags=3 vbmeta minted by avbtool is the smallest valid blob that disables both layers.

Same forum advice. Two completely different files. One of them boots.