Fastboot

Flashing vendor_boot and dtbo Partitions with Fastboot

Published: July 6, 2026 • Applies to: Devices launched with Android 10 and later on Treble-compliant hardware

Older flashing guides only mention boot.img, because that used to be where the kernel, ramdisk, and device tree all lived together. Devices launched with Android 10 or later on Project Treble hardware split that single image into three separate partitions, and flashing only boot.img on one of these devices while ignoring the other two is a common reason a custom kernel or GSI boots into a black screen or bootloop.

Why the Split Happened

Google's Generic Kernel Image (GKI) initiative required separating the parts of a boot image that vendors customize from the parts that stay generic across devices, so a single generic kernel image could work across many OEMs. The practical result is three partitions instead of one:

boot — the kernel image and a generic ramdisk.
vendor_boot — the vendor-specific ramdisk, containing device-specific init scripts and drivers needed at early boot.
dtbo — the Device Tree Blob Overlay, describing hardware configuration variants for the same board (different display panels, memory configurations, and similar hardware revisions sharing one firmware build).

Confirming Whether Your Device Has These Partitions

fastboot getvar current-slot
fastboot flash vendor_boot vendor_boot.img

If the device does not have a vendor_boot partition (older devices, or some budget models that still use the legacy single boot image), the command fails immediately with a "partition does not exist" error, which is a safe, non-destructive way to check before assuming a ROM's flashing instructions apply as written.

Flashing Each Partition

fastboot flash boot boot.img
fastboot flash vendor_boot vendor_boot.img
fastboot flash dtbo dtbo.img

All three should come from the same firmware build or ROM release. Mixing a boot.img from one build with a vendor_boot.img from a different build is one of the most common causes of a device that boots partway to a manufacturer logo and then reboots in a loop, since the generic kernel and the vendor ramdisk need to agree on kernel module versions and init behavior.

A/B Slot Devices

On devices with A/B seamless updates, these partitions exist as _a and _b variants internally, but a plain fastboot flash boot boot.img automatically targets whichever slot is currently active — there is no need to specify the suffix manually in routine flashing. To target the inactive slot explicitly instead:

fastboot flash boot_b boot.img

When Only dtbo Needs Reflashing

A dtbo mismatch produces a distinct symptom from a bad boot or vendor_boot image: the device usually boots normally into the OS, but a specific piece of hardware misbehaves — the display shows wrong colors or refresh rate, a sensor is not detected, or touch input is unresponsive in one screen orientation. If a ROM update changelog specifically mentions a dtbo fix, reflashing just that partition without touching boot or vendor_boot is enough:

fastboot flash dtbo dtbo.img
fastboot reboot

GKI and Root: A Practical Note

On a Generic Kernel Image device, patching for Magisk root still happens on boot.img the same way it does on non-GKI devices, but the vendor_boot partition is what actually loads the vendor's kernel modules at early boot. Flashing a Magisk-patched boot.img without a matching, unmodified vendor_boot from the same build is a frequent cause of Wi-Fi or cellular modem failing to initialize after rooting, since the generic kernel expects the vendor's module set to match exactly.

Back Up the Originals Before Flashing

fastboot getvar all
adb pull /vendor_boot vendor_boot_backup.img

Pulling directly from the mounted partition path via ADB requires root; without it, dump each partition through fastboot before modifying anything instead, since restoring stock firmware after a bad flash is far easier with a known-good original image already saved locally than by hunting for a matching firmware package after the fact.

A Newer Split Still: init_boot

Devices launched on very recent Android releases add yet another partition, init_boot, which carries the generic ramdisk that used to live inside boot.img directly. This further split matters for root patching specifically, since some Magisk-based root methods on these newer devices patch init_boot.img rather than boot.img, and applying an older guide's boot-patching instructions unmodified on one of these devices produces a device that boots but never actually root-permits, because the patch landed in the wrong partition entirely.

Confirming the Flash Actually Took Effect

fastboot getvar partition-type:vendor_boot

Fastboot's getvar command can confirm a partition's reported type after flashing, though the most reliable confirmation remains simply rebooting and checking that the device boots to a normal, functioning home screen with the expected build number visible under About Phone, rather than relying solely on fastboot's own success message for the flash command itself.