Fastboot's error messages are terse by design — they come straight from the bootloader, not from a polished tool, so a single line like FAILED (remote: Partition not found) has to stand in for a range of underlying causes. Matching the exact wording to the actual cause saves a lot of guessing.
This means the bootloader has no partition by the name you specified in the command, most commonly fastboot flash recovery recovery.img on a device that doesn't expose a standalone recovery partition. The most frequent cause is targeting an A/B device (see our dynamic partitions guide) with a command written for older non-A/B partition layouts, where recovery is merged into the boot partition rather than existing on its own.
Check the partition list your specific device actually exposes with:
fastboot getvar all
and compare the partition name in your command against what the device reports. A typo in the partition name (a very easy mistake with names like vbmeta_a versus vbmeta) produces the identical error message.
The image file you're flashing is bigger than the partition it's being written to. This shows up when flashing a system image or GSI that wasn't built with your device's exact partition size in mind, or when a custom recovery build has grown larger than the stock recovery partition it's replacing on an older device with a small fixed recovery partition. Check the reported partition size against your image's file size; there's rarely a workaround beyond finding a build sized correctly for your device.
The bootloader checked the image against its expected signing key and rejected it, because the image wasn't signed by whoever holds the OEM's private signing key. On a locked bootloader, this is by design and blocks anything except OEM-signed images. On an unlocked bootloader that still throws this error, either the unlock didn't fully take effect, or the specific partition (commonly vbmeta) still has its verification flag enabled even though the general bootloader unlock succeeded. See our guide to flashing vbmeta with verification disabled for the fix.
Some devices enforce an anti-rollback counter that blocks flashing an older firmware version once a newer one has booted, as a security measure against downgrade attacks. If this error appears while trying to flash an older firmware build than what's currently installed, the device's anti-rollback protection is the cause, and there generally isn't a way around it through fastboot alone — you'd need a firmware build at or above the currently enforced anti-rollback index.
This isn't a flash error exactly, but it's often mistaken for one — the command isn't failing, it's waiting indefinitely because fastboot can't see the device at all. This is a driver or cable problem rather than a flashing problem: check fastboot devices on its own first, and if that returns nothing, work through the driver installation for your specific brand before troubleshooting the flash command itself.
Some flash targets, particularly the dynamic partitions inside super.img (system, vendor, product), require fastbootd — the userspace fastboot implementation reached via fastboot reboot fastboot — rather than the bootloader-level fastboot. Flashing one of these partitions from plain bootloader-mode fastboot instead of fastbootd can produce a partition-not-found style error even though the partition genuinely exists, simply because it isn't visible from that mode. See our dynamic partitions guide for which partitions need which mode.
fastboot getvar all first and compare the partition names and current slot against what your command targets.