Batocera 43 Download: 12 Steps to Flash in 40 Minutes

There is a particular kind of person who types "batocera download" into a search box and expects a single button, a single file, and a single outcome. That person is about to be disappointed, and the disappointment is healthy. Batocera is not an app. It is a full Linux distribution — a free, open-source retro-gaming operating system that you copy onto a USB stick or SD card and boot from, replacing whatever was running on the machine for as long as the stick is plugged in. The project's own framing is blunt about it: download, flash, connect and play. Four verbs, and only the first one is what most people mean when they say "download."

This tutorial covers all four, in order, with version numbers pinned to what was actually shipping in mid-2026 rather than whatever the wiki said in 2021. The current release at the time of writing is Batocera 43, codenamed "Glasswing," with a release entry dated 2026/05/08. If you are reading this and the version number has rolled forward, the procedure does not change — the filenames and the changelog do. I will tell you how to read both so you are never dependent on an article aging gracefully, because articles never do.

Budget about forty minutes from cold start to a booted EmulationStation menu, assuming a decent USB 3.0 stick and a download that is not throttled to dial-up speeds. Most of that forty minutes is the flash and the first-boot partition resize, neither of which you control. The parts you do control — picking the right image and not corrupting it — take five minutes and prevent ninety percent of the forum posts.

What "Download" Actually Means Here

Three distinct things hide under the word "download" in the Batocera world, and conflating them is the root of most confusion.

The first is downloading the disk image: a compressed .img.gz file from batocera.org/download that you write to physical media. This is the install. You do it once per device, or once per major-version jump if you choose the clean route instead of the in-place upgrade.

The second is downloading an update — pulling a newer build of the same major release, or hopping to a newer major release entirely, through Batocera's own update machinery rather than re-flashing. This is what the MAIN MENU → UPDATES & DOWNLOADS path and the batocera-upgrade command are for.

The third is downloading content — games, ROMs, BIOS files, scraped artwork — from inside the running system. Batocera 43 will happily run a Flatpak'd Firefox and a Flatpak'd p7zip so you can fetch and unpack archives without ever leaving the couch.

The download page itself is organized by hardware target, not by "newest first." In 2026 it still splits cleanly into builds for PCs, handheld consoles, Raspberry Pi boards, Odroid boards, and a long tail of other devices. You do not pick the "latest" Batocera; you pick the latest Batocera for your specific board, and those are different files with different names. Get this wrong and you will flash a perfectly valid image that simply will not boot on your hardware, then conclude the download was "corrupted." It was not. You downloaded the wrong architecture.

Prerequisites: Hardware and Software Versions

Nothing here is exotic, but vagueness is where installs die. Pin everything.

Target hardware (one of):

• x86_64 PC or mini-PC — any 64-bit Intel or AMD machine from roughly the last fifteen years. For modern handhelds and mini-PCs, Batocera 43 explicitly prefers the x86_64-v3 image, which supports AMD and Intel graphics on Wayland. The v3 image assumes a CPU with the AVX2-era instruction set (Haswell/2013 and later for Intel, Excavator/2015 and later for AMD). If your box predates that, take the plain x86_64 image, not v3.
• Raspberry Pi — Pi 4 (4GB+) or Pi 5 strongly preferred. A Pi 3 will boot but you will feel every megahertz it lacks.
• Odroid — XU4, N2/N2+, and the usual suspects each have their own image.
• Android TV box, Steam Deck, or other retro console — Batocera's cross-device reach in 2025–2026 spans Android TV boxes, PCs, retro consoles, the Steam Deck, and Raspberry Pi boards. The image you pick still maps to the underlying silicon.

Storage media:

• A USB 3.0 flash drive or SD card, 32GB minimum. 16GB technically works for the OS but leaves you nothing for games. For SD cards, a genuine A1/A2-rated card from a brand that exists; counterfeit cards are the single most common cause of "random corruption" reports.

Software on the machine you flash from:

• Balena Etcher 1.18 or newer from etcher.balena.io. Etcher reads the .img.gz directly — you do not decompress it first. This matters: decompressing then flashing the raw .img works too, but Etcher's gz handling is faster and skips a 7–9GB temporary file.
• Alternatively, command-line dd on Linux/macOS, or Raspberry Pi Imager if you are a Pi person who likes a UI. I will cover dd for the people who insist.
• A SHA verification tool — sha256sum on Linux, shasum -a 256 on macOS, CertUtil on Windows. You already have it.

That is the entire bill of materials. No license keys, no accounts, no "create a profile to continue." It is a free, open-source distribution and behaves like one.

Picking the Correct Image for Your Target

Go to batocera.org/download. The homepage's "Download" call-to-action routes here too, so either entry point lands in the same place. You will be asked, in effect, two questions: what hardware and what version.

The version answer is almost always "the current stable," which as of this writing is Batocera 43 "Glasswing." The hardware answer is where you slow down. Read the build name. Batocera's filenames are descriptive to the point of redundancy, and that redundancy is your friend. A historical example from the Linux.org forums shows a user grabbing the PC build as batocera-x86_64-x86_64-38-20231014.img.gz — that was Batocera 38, older than our target window, but the naming convention is unchanged. Decode it:

batocera-x86_64-x86_64-38-20231014.img.gz
         |        |       |  |
         |        |       |  └─ build date (YYYYMMDD)
         |        |       └──── major version (38)
         |        └──────────── architecture / sub-target
         └───────────────────── platform family

# A 2026 x86_64-v3 build follows the same shape, e.g.:
batocera-x86_64_v3-43-2026MMDD.img.gz
         |           |  |
         |           |  └─ dated build within release 43
         |           └──── major version (43, "Glasswing")
         └──────────────── x86_64-v3 target (AVX2-class CPUs)

If the filename in your downloads folder does not contain your architecture, you grabbed the wrong file. There is no penalty for re-downloading; there is a large penalty for flashing the wrong one and spending an hour blaming Etcher.

For 2026 handhelds and mini-PCs specifically: the changelog notes that x86_64 handhelds with AMD and Intel graphics are supported on the x86_64-v3 image using Wayland. If you are installing on a modern AVX2-class handheld, the v3 image is the preferred target, not the legacy x86_64 one. The non-v3 image still exists precisely for older silicon that lacks those instructions; flashing v3 to a pre-Haswell box yields a machine that posts and then sits there, which people misread as a dead download every single day.

The 12-Step Download-to-Boot Procedure

Here is the whole thing, start to finish, with the reason each step exists. Skipping a step is allowed; pretending the step did not matter when it later bites you is not.

1. Identify your exact hardware target. Rationale: the download page is organized by device family, and the architecture in the filename must match your CPU/board. Everything downstream depends on this single decision.
2. Open batocera.org and click "Get Batocera Linux" / "Download." Rationale: this is the only canonical source. Third-party mirrors and "pre-loaded" cards on auction sites are how people acquire malware and ten-version-old builds.
3. Select the build for your device and start the download. Rationale: you want the current stable (Batocera 43 at time of writing). The file is a .img.gz in the multi-gigabyte range; let it finish completely.
4. Record the published checksum. Rationale: the download page or its mirror lists a SHA256 (or similar) for each image. You will compare against it in step 5. A truncated download is the most common silent failure.
5. Verify the downloaded image against the checksum. Rationale: flashing a corrupt image produces a card that boots partway, or not at all, with symptoms identical to a hardware fault. Five seconds of hashing saves an hour of misdiagnosis. (Commands in the next section.)
6. Install or update Balena Etcher (1.18+). Rationale: older Etcher builds have rougher gz handling and stale drive-detection. Get it from etcher.balena.io, not a software portal that bundles junk.
7. Insert the USB stick or SD card and identify it correctly. Rationale: flashing writes to the whole device and destroys everything on it. Misidentifying the target is how people wipe an external backup drive. Etcher hides system drives by default; respect that.
8. In Etcher: select the .img.gz, select the target, click Flash. Rationale: Etcher decompresses on the fly and verifies the write automatically. Let the verification pass run; do not yank the stick when the progress bar hits 100% — wait for "Flash Complete."
9. Eject the media cleanly, move it to the target machine. Rationale: an unflushed write cache corrupts the last megabytes of the image — frequently the bootloader. "Eject," not "pull."
10. Set the target machine to boot from USB/SD. Rationale: PCs need a one-time boot-menu key (F12/F11/Esc, vendor-dependent) or a BIOS change disabling Secure Boot and enabling USB boot. Pi/Odroid boot from the card automatically if no other OS interferes.
11. Boot Batocera and let it resize the partition. Rationale: on first boot Batocera expands its data partition to fill the media. This takes a few minutes and a reboot; interrupting it leaves a half-sized userdata partition and mysterious "disk full" errors later.
12. Press F1 to open the file manager and begin copying games, ROMs, and BIOS. Rationale: this is the post-flash content step. F1 opens Batocera's built-in file manager so you can move ROMs into the per-system folders and BIOS files into bios/ without pulling the card back out. After that, exit, refresh the game list, and you are playing.

That is twelve steps. Ten of them are mechanical and forgiving; steps 1 and 5 are the two that actually decide whether you succeed, which is exactly why people skip them.

Verifying the Download Before You Flash

This is the step the impatient skip and the experienced never do. The published checksum on the download page is the only way to know your multi-gigabyte file arrived intact. Run the hash, compare the string, move on.

# Linux
sha256sum batocera-x86_64_v3-43-2026MMDD.img.gz

# macOS
shasum -a 256 batocera-x86_64_v3-43-2026MMDD.img.gz

# Windows (PowerShell / cmd)
CertUtil -hashfile batocera-x86_64_v3-43-2026MMDD.img.gz SHA256

Expected output looks like this — a single 64-character hex string followed by the filename:

$ sha256sum batocera-x86_64_v3-43-2026MMDD.img.gz
3f9a1c0b7e2d4856a1b9c3d2e4f50617\
2839a4b5c6d7e8f90a1b2c3d4e5f6071  batocera-x86_64_v3-43-2026MMDD.img.gz

Compare that string, character for character, against the one published next to the image. If they match, the download is bit-perfect. If they differ — even by one character — delete the file and download again. Do not flash it "to see if it works." It will not, and the failure mode will waste far more time than the re-download.

For the people who refuse Etcher: here is the dd route on Linux. It is unforgiving — one wrong device node and you overwrite your system disk — so identify the target with lsblk first and read it twice.

# 1. Find the target. Note SIZE to confirm it is your stick, not /dev/sda.
lsblk -o NAME,SIZE,MODEL,TRAN

# 2. Decompress and write in one pipe. Replace sdX with YOUR device,
#    and use the whole device (sdX), NOT a partition (sdX1).
gunzip -c batocera-x86_64_v3-43-2026MMDD.img.gz \
  | sudo dd of=/dev/sdX bs=4M status=progress oflag=sync

# 3. Flush caches before removing the media.
sync

Expected dd output streams a running byte count and ends with a throughput summary — something like 9123456789 bytes (9.1 GB) copied, 312 s, 29.2 MB/s. When sync returns to the prompt, the write is genuinely complete and you can pull the media. If you skip sync, the kernel may still be flushing and you will eject a subtly broken bootloader.

First Boot and the F1 File Manager

Plug the flashed media into the target, power on, and trigger USB/SD boot. On a PC that usually means hammering the one-time boot-menu key during POST and choosing the USB device. If the machine boots straight into Windows instead, you either missed the key or Secure Boot is blocking the unsigned bootloader — disable Secure Boot in the firmware and try again.

The first boot is slower than every subsequent boot because Batocera resizes its data partition to fill the media and then reboots itself once. Let it. When EmulationStation — the front-end menu — finally appears, the OS is live and running entirely from the stick. Nothing has touched the machine's internal drive. Pull the stick later and the machine boots its normal OS as if Batocera never happened. This is the whole appeal: a non-destructive, bootable retro console you carry in a pocket.

Now for content. The standard post-flash workflow demonstrated in 2026 install walkthroughs is exactly this: extract the USB, boot it, then press F1 inside Batocera to open the file manager and begin copying games, ROMs, and BIOS files. The file manager lets you move files into the right places without shutting down and re-mounting the card on another computer:

• ROMs go under /userdata/roms/<system>/ — one folder per console (nes, snes, psx, and so on).
• BIOS files go under /userdata/bios/. Many emulators refuse to start without the correct, correctly-named BIOS; this is not Batocera being difficult, it is the cores enforcing what the original hardware required.
• Saves, scraped artwork, and configs land under /userdata/ as well — the entire writable world lives in that one partition, which is also why it is the only thing you back up.

After copying, exit the file manager and refresh the game list (the menu offers "Update Gamelists," or just reboot). Your systems now appear populated. The legality of where those ROMs came from is between you and the relevant statute; the file manager does not ask, and neither will I, beyond noting that dumping your own cartridges is the only path that keeps a copyright lawyer bored.

Update Branches and the Command Line

Once Batocera is running, you do not re-download the whole image to move forward. You update in place. There are two channels and two interfaces, and understanding the branch system keeps you from accidentally riding bleeding-edge builds on a machine you wanted to be stable.

In the UI, the path is MAIN MENU → UPDATES & DOWNLOADS → UPDATE TYPE. "Stable" is the default and the correct choice for anyone who wants their console to keep working. The other branches exist for testers. Under the hood this is just a line in the config file at /userdata/system/batocera.conf, and you can set it directly:

# /userdata/system/batocera.conf
# Update branch selection. "stable" for normal use.
# Other named branches (e.g. the beta channel) pull newer,
# less-tested builds. Set deliberately, not by accident.
updates.type=butterfly

The wiki documents updates.type=butterfly as the branch-selection setting; "butterfly" is a named branch, not a synonym for "latest stable," so know which branch name you are pointing at before you commit a machine to it. Edit this only when you mean to; the UI toggle exists so you do not have to.

For the command line — over SSH, or from a terminal — Batocera ships two tools that do exactly what their names say:

# Check what the latest available version is for your branch.
batocera-check-updates

# Install it.
batocera-upgrade

Expected output from a check, when an update is waiting, is a short report naming the available build; when you are current, it tells you so and exits. A real session reads roughly like this:

$ batocera-check-updates
Current version: 43
Latest available: 43 (build 2026MMDD)
A newer build is available for branch: stable

$ batocera-upgrade
Downloading update ...
  boot.tar.xz  [############################] 100%
Verifying download ...
Installing. DO NOT POWER OFF.
Upgrade complete. Reboot to apply.

There is also an advanced form of the upgrade that accepts a specific build-folder URL, for people who need to pin an exact build rather than "whatever the branch currently points at." That capability ties into Batocera's update-server format: the wiki gives an example where you replace the mirror domain with https://updates.batocera.org/, which the project says hosts the current and beta releases. If you ever need to point a fleet of machines at an internal mirror, that is the lever — substitute your own host for that domain and serve the build folders behind it. The full mechanics live in the official Batocera wiki, which is the primary source for anything update-related and the only one I would trust over a forum post.

One historical note for context: the prior major release, Batocera 42, was documented by AndroidPCtv as adding emulator-core updates and general settings improvements, with users able to update either through the System Menu's Update path or by downloading the Batocera 42 update package directly. The two-path pattern — in-UI update versus fetch-the-package — has been stable across releases, which is why the procedure above survives version bumps.

Downloading Games From Inside Batocera

The third meaning of "download" — pulling content while Batocera is running — deserves its own section because the tooling is genuinely good now and most people do not know it exists. A 2026 tutorial focused on direct in-system downloading demonstrates using Flatpak applications inside Batocera: specifically Mozilla Firefox for browser access and p7zip for archive extraction. Batocera supports Flatpak as a first-class way to add desktop apps without polluting the base image.

The practical loop is: install Firefox via Flatpak, browse to wherever your legally-acquired content lives, download the archive, then use p7zip to extract it into the right ROM folder. On the command line the Flatpak installs look like this (names may vary slightly by Flathub remote):

# Add the Flathub remote if it is not already present.
flatpak remote-add --if-not-exists flathub \
  https://flathub.org/repo/flathub.flatpakrepo

# A browser, for fetching content from inside Batocera.
flatpak install -y flathub org.mozilla.firefox

# 7-Zip / p7zip, for unpacking .7z and .zip archives in place.
flatpak install -y flathub org.7zip.Archiver   # or use the bundled p7zip

# Extract an archive into the correct system folder:
7z x ~/Downloads/somegame.7z -o/userdata/roms/snes/

The advantage over the F1-file-manager-and-another-PC dance is obvious: a handheld or a couch-bound mini-PC never needs a second computer in the loop. The disadvantage is that a browser on a 10-foot interface is exactly as pleasant as it sounds, so this is a convenience, not a primary workflow, for large libraries. For bulk loading, network share or pulling the card is still faster.

Common Pitfalls and Their Fixes

Five failure modes account for the overwhelming majority of "it doesn't work" reports. None of them are bugs. All of them are skipped steps wearing a costume.

1. Wrong architecture downloaded. Symptom: flashes fine, boots to a black screen or instant reboot loop, or simply does nothing. Cause: an x86_64-v3 image on a pre-AVX2 CPU, or a Pi image on a PC, or vice versa. Fix: re-read the filename, confirm it contains your architecture, and re-download the correct target. The v3 image needs AVX2-class silicon; older boxes take the plain x86_64 build.
2. Corrupt or truncated download. Symptom: flash fails verification, or boots partway then hangs. Cause: an interrupted download, a flaky connection, or a full disk during download. Fix: run sha256sum against the published checksum (see above). Mismatch means delete and re-download — never flash an unverified image.
3. Flashing a partition instead of the whole device. Symptom (dd users): the stick will not boot at all. Cause: writing to /dev/sdX1 instead of /dev/sdX. Fix: target the whole device node. Etcher does this correctly by default; this is purely a command-line foot-gun.
4. Pulling the media before the write flushes. Symptom: intermittent boot failures, especially on the bootloader. Cause: yanking the stick at 100% before the OS finished flushing its write cache. Fix: "Eject" in the OS, or run sync and wait for it to return, before removing the media.
5. Interrupting the first-boot partition resize. Symptom: "disk full" errors after copying only a few games, despite a 64GB card. Cause: powering off during the one-time partition expansion. Fix: re-flash and let the first boot complete its resize-and-reboot cycle untouched. It is slow on purpose, exactly once.
6. Secure Boot blocking the PC bootloader. Symptom: the machine ignores the USB stick and boots its internal OS. Cause: UEFI Secure Boot rejecting Batocera's bootloader. Fix: disable Secure Boot in firmware and enable USB boot, then use the one-time boot menu to select the stick.

Troubleshooting Table

Advanced Tips

Read the changelog as a primary source, not the forums. Batocera's changelog is the cleanest authoritative record of what each version actually changed. Release 43 "Glasswing" (2026/05/08) is documented there alongside version-specific emulator-core updates — for instance the Libretro PS2 core advanced to a 2026/02/06 build and Libretro PUAE (Amiga) to a 2025/11/02 build. When someone insists a core "is broken in this version," the changelog tells you whether the core even moved. Bookmark it.

Treat /userdata as the entire backup surface. Every save, config, scraped image, and ROM lives under that one partition. Back it up and you can re-flash a fresh image, drop the partition contents back, and lose nothing. This also means your update strategy can be aggressive — if an in-place upgrade misbehaves, re-flash clean and restore userdata.

Pin builds for fleets. If you run more than one machine and want them identical, use the advanced batocera-upgrade form that accepts a specific build-folder URL, served from your own mirror in place of updates.batocera.org. Identical builds mean identical bugs, which is the goal — reproducibility beats novelty when you support other people's machines.

Prefer Wayland on modern x86_64 handhelds. The x86_64-v3 image's Wayland path on AMD/Intel graphics is the supported configuration for current handhelds in the 43 cycle. Fighting it back to an older display stack is a way to trade one set of glitches for an unsupported set.

SSH in for everything tedious. Batocera exposes SSH (default credentials are documented on the wiki; change them on anything network-facing). Bulk file moves, config edits, and the update commands are all faster over SSH than through a 10-foot UI. The wiki covers enabling it.

Know your cores' upstreams. Batocera's emulators are largely libretro cores fronted by RetroArch. When a specific system behaves oddly, the real documentation is upstream: the libretro / RetroArch docs and the core repositories under the libretro GitHub organization. Batocera packages these; it does not write most of them. And the distribution itself is on GitHub at batocera-linux/batocera.linux if you want to read the build system or file an issue against the actual project rather than shouting into a subreddit.

A Complete Working batocera.conf

Here is a minimal, sane /userdata/system/batocera.conf covering the settings this tutorial touched, annotated so you know why each line exists. Batocera's config is key=value; unset keys fall back to defaults, so a short file is a feature, not an omission. Edit it over SSH or from the F1 file manager, then reboot.

# /userdata/system/batocera.conf
# ---- Update channel -------------------------------------------------
# "stable" is the default and correct for daily use. Named branches
# (e.g. butterfly) pull newer, less-tested builds. Set deliberately.
updates.type=stable

# ---- System basics --------------------------------------------------
system.language=en_US
system.kblayout=us
system.timezone=America/New_York
system.hostname=batocera

# ---- Networking (enable SSH for headless file moves & updates) ------
wifi.enabled=1
# wifi.ssid=YOUR_SSID
# wifi.key=YOUR_PASSPHRASE
system.ssh.enabled=1

# ---- Display: prefer Wayland on modern x86_64-v3 handhelds ----------
# Leave at default unless you have a specific reason; the v3 image
# targets AMD/Intel graphics on Wayland for the 43 cycle.
# global.videomode=default

# ---- Global emulator defaults (override per-system as needed) -------
global.smooth=1
global.rewind=0
global.autosave=0
global.retroachievements=0

# ---- Per-system example: bump a heavy core's settings ---------------
# PS2 via libretro (core advanced to a 2026/02/06 build in 43).
ps2.videomode=default
ps2.smooth=1
# Amiga via libretro PUAE (2025/11/02 build in 43).
amiga.core=puae

# ---- Scraper (artwork/metadata) -------------------------------------
scraper.source=ScreenScraper
# scraper.screenscraper.user=YOUR_USER
# scraper.screenscraper.password=YOUR_PASS

Flash the right image, verify it, let the first boot finish, and keep your config short and intentional. That is the entire discipline. Batocera rewards people who read filenames and punishes people who guess at them, and now you are firmly in the first camp. Download, flash, connect, play — in that order, exactly once per device, and the next forty minutes are the last forty minutes you spend thinking about the operating system instead of the games.