Batocera 43.1 Download: 12 Steps to Flash, 30 Min

Batocera does not install. Read that twice, because a good half of the support threads that end in a factory reset and a foul mood begin by ignoring it. Windows installs. Batocera boots — from a USB stick or an SD card you flashed on some other machine — and it does not so much as exhale on the drive already sitting inside your computer. There is no bootloader to repair, no partition to shrink, no dual-boot menu to babysit. Pull the stick out, reboot, and the machine is the same beige Windows box it was an hour ago. That single design decision is the reason this tutorial exists, and it is the first thing to internalise before you touch a flasher.

This guide covers the current mid-2026 release, Batocera 43.1 “Glasswing,” from download to a working front-end in roughly twelve steps and half an hour of wall-clock time — most of which is the flasher and the first-boot expansion doing their thing while you drink something. It is written for a modern x86 desktop, laptop, NUC, or mini PC, because that is where 43.1 does its best work. Everything below is tested against the official documentation, not a content farm; if a step contradicts a YouTube “2026 setup” video, trust the wiki.

What Batocera Actually Is (and Isn't)

Before you flash anything, understand what you are flashing. Batocera is not an emulator. It is a complete, self-contained Linux distribution whose entire reason for living is to boot straight into the EmulationStation front-end, hand you a couch-friendly menu, and get out of the way. It first shipped in 2016, it has been updated continuously into 2026, and it belongs to the same EmulationStation lineage as RetroPie and Recalbox — but with a broader hardware net and a stricter no-touch philosophy about your existing OS.

A read-only console that leaves your PC alone

The image you flash splits into two partitions. The first is a small FAT boot partition holding a compressed, read-only SquashFS system: the kernel, EmulationStation, and 200-plus emulator cores, none of which you can accidentally corrupt because the operating system mounts itself immutable. The second partition, userdata, is the only place anything is ever written — your ROMs, saves, configuration, and scraped box art. Break your settings badly enough and the fix is to wipe userdata and start over; the OS itself cannot rot. It behaves far more like a console's firmware than a desktop Linux install, and that is the whole point. Because it runs entirely from removable media, it requires no modification of the host computer and preserves the machine's original OS and data intact.

Free as in freedom, and free as in zero dollars

Batocera is 100% open source and costs exactly nothing. The source lives on the batocera-linux/batocera.linux repository, the licence is Creative Commons non-commercial share-alike, and the copyright line reads 2016–2026 because the project has shipped for a decade. There is no paid tier, no unlock, no upsell, and anyone who tries to sell you “the Batocera download” is selling you a free thing with a markup. What it emphatically does not ship is content: not one game, not one console BIOS. The distribution is legal precisely because it is empty. Filling it is your job, and — we will be blunt about this in the games section — the law cares a great deal about how you do it.

Why emulation, and where it stops

Batocera is software emulation, which means compatibility measured in the hundreds of systems and accuracy measured in “good enough for almost everything.” If you are chasing frame-perfect, latency-exact reproduction of original silicon, that is the domain of FPGA hardware like the MiSTer Multisystem 2, not a $120 mini PC. For the other 99% of a library — from the Atari 2600 up through the PlayStation 2 and Dreamcast — a modern x86 box running Batocera will out-run any single-board handheld, and it will do it from a USB stick you can pocket. Set your expectations there and you will not be disappointed. Under the hood, most of those systems run on the same libretro cores you would configure by hand in RetroArch — Batocera just wires them up for you.

Prerequisites & Hardware Floor

Skipping this section is how people end up flashing three times. Batocera's requirements are modest, but two of them — the storage floor and the CPU instruction set — have hard cliffs, and falling off either produces failures that look like a corrupt download when they are nothing of the sort.

The hardware floor (and the number nobody reads)

The published minimums are 1 GB of RAM (2 GB recommended) and 16 GB of storage (32 GB recommended). The RAM number is generous; anything from the last fifteen years clears it. The storage number is the one that bites: below 16 GB, Batocera disables its own auto-update mechanism, because it cannot guarantee enough headroom to stage a new system image safely. Use an 8 GB stick and you have signed up to reflash by hand for the life of the install. Buy a 32 GB or larger USB 3.0 stick — they cost less than a sandwich — and never think about it again. A cheap Intel N100 mini PC such as a Beelink Mini S12 is the archetypal target: silent, sub-$150, and comfortably ahead of any handheld.

The x86_64-v3 gotcha

Batocera 43.1's preferred desktop image is built for the x86_64-v3 microarchitecture level. In plain terms, that means a CPU with AVX2 and the associated instruction extensions — roughly Intel Haswell (2013) or AMD Excavator and newer. On a compatible chip this image is faster and better-supported; on a pre-2013 CPU it will refuse to boot with an illegal-instruction fault that looks, misleadingly, like a bad flash. The v3 build also brings a Wayland session on the LabWC compositor, and it treats AMD and Intel graphics as first-class while leaving Nvidia drivers experimental. If your box has an Nvidia GPU, budget time for the experimental path or plan around the integrated graphics. Machines older than Haswell should download the plain legacy x86_64 image instead.

Software you need before you start

You need exactly three things on the machine you are flashing from: a flasher, a decompressor, and a spare stick. For the flasher, balenaEtcher is the cross-platform default and it will write a compressed .img.gz directly without unpacking it first. On Windows, Rufus works too, but only in DD Image mode — its default ISO mode will quietly mangle a Batocera .img. On Linux or macOS, dd is all you need. For decompression, use 7-Zip on Windows or gunzip on Linux/macOS, unless you are letting Etcher swallow the .gz whole. That is the entire toolchain, and every piece of it is free; a 2026 walkthrough titled “Install Batocera Linux on a Mini PC” demonstrates the same Rufus-or-Etcher flow with no paid software anywhere in it.

Choosing the Right Image

Everything downstream depends on grabbing the correct file, so slow down for one screen. The official source — the only source you should use — is the batocera.org download page. It lists the current 43.1 build for Desktop PC, Laptop, NUC, and Intel-based Apple devices, alongside the SBC targets. Anything hosted elsewhere is at best a mirror and at worst a repackaged installer with something extra inside.

Reading the download page without getting lost

The page groups images by hardware family. For the machines this tutorial targets, you want the PC/x86 family and, within it, the x86_64-v3 image described in the prerequisites. The file arrives as a compressed disk image — a .img.gz of roughly 3 GB that decompresses to about 8 GB written to the stick. That 8 GB is the base system plus an empty userdata partition; it grows to fill your media on first boot. If you would rather cross-reference versions and dates, the wiki keeps a current-and-previous-releases page, and the raw history lives in the Batocera-Changelog.md on GitHub.

x86_64 vs x86_64-v3 vs board images

Three families cover almost everyone. The x86_64-v3 image is the modern default and what you should pick unless you have a reason not to. The plain x86_64 image is the compatibility fallback for pre-2013 CPUs. The board-specific images (Raspberry Pi 5, various ARM SBCs) are a different download entirely and are not interchangeable with the PC images. This last point is worth dwelling on if you are weighing a PC build against a Pi: Batocera and Recalbox both ship official Pi5 images, whereas RetroPie still does not — a gap we picked apart in our look at RetroPie's missing x86 story. On a PC, Batocera is simply the path of least resistance.

Verifying the download before you trust it

A 3 GB download can arrive subtly damaged, and a damaged image flashes a brick that wastes twenty minutes proving it will not boot. If the download page publishes a checksum alongside the image, verify it before flashing. If it does not, balenaEtcher performs a read-back validation after writing that catches most media-level corruption anyway. Verification costs seconds; a mystery non-boot costs an afternoon.

# Linux / macOS: confirm the download landed intact
# (compare the printed hash to the value on the download page, if one is published)
sha256sum batocera-x86_64_v3-43.img.gz

# Expected: a 64-character hex string, e.g.
# 9f2c...a71e  batocera-x86_64_v3-43.img.gz

The 12-Step Flash

Here is the whole procedure, start to finish, with the reasoning attached to each step so you know why and not just what. Follow it in order. The dangerous steps are 5 and 6 — identifying and writing the target device — and everything else is patience.

1. Confirm your CPU speaks x86_64-v3. Check that the target machine is Haswell-era (2013) or newer. Rationale: flashing the v3 image onto an older CPU produces an illegal-instruction crash that masquerades as a corrupt download and sends people flashing in circles.
2. Download the correct image from batocera.org/download. Pick the x86_64-v3 build under the PC family (or legacy x86_64 for old hardware). Rationale: the download page is the only trustworthy source, and the hardware family must match your machine.
3. Verify the checksum if one is offered. Run sha256sum and compare. Rationale: a silently truncated 3 GB file flashes cleanly and then never boots — catch it now, not at step 9.
4. Decompress, or let the flasher do it. Unpack the .img.gz with 7-Zip or gunzip, unless you are using balenaEtcher, which reads the compressed file directly. Rationale: the ~3 GB archive expands to ~8 GB written; some tools need the raw .img.
5. Insert a 32 GB+ USB 3.0 stick and identify it precisely. Note the exact device node (Linux lsblk) or the exact drive letter/name (Etcher, Rufus). Rationale: dd does not ask for confirmation. Point it at the wrong disk and you erase that disk, permanently.
6. Flash the image. Use balenaEtcher (any OS), Rufus in DD Image mode (Windows), or dd (Linux/macOS). Rationale: Rufus's default ISO mode corrupts a raw .img; DD mode writes it byte-for-byte.
7. Wait for write-and-validate, then eject safely. Let the flasher finish its verification pass before removing the stick. Rationale: yanking the drive mid-write or mid-validate leaves a truncated, unbootable image.
8. Set the target PC to boot from USB. Use the one-time boot menu (often F12) or enter firmware setup, disable Secure Boot, and move the USB above the internal drive. Rationale: otherwise the machine ignores the stick and boots Windows as usual.
9. Boot and let userdata auto-expand. On first boot Batocera grows its data partition to fill the media; do not interrupt it. Rationale: pulling power during expansion corrupts the partition table and forces a reflash.
10. Map your controller. Hold a button until the mapping wizard appears and assign every input, including a hotkey. Rationale: the hotkey combination is how you save states and, more importantly, how you exit a game back to the menu.
11. Connect the network and enable access. Join Wi-Fi or plug in Ethernet, then confirm the Samba share and SSH are reachable. Rationale: this is the pipe through which you will copy games; setting it up now saves shuttling USB sticks later.
12. Copy ROMs and BIOS, then Update Gamelists. Drop files into the correct folders over the network and refresh the library. Rationale: a system only appears in the menu once its folder holds a valid game, and the list will not refresh itself.

The command-line flash, end to end

If you are on Linux or macOS and prefer the terminal to a GUI, the entire flash is three careful commands. The one that matters is the device name: write to the whole disk (/dev/sdX), never a partition (/dev/sdX1), and triple-check that X is your USB stick and not your system drive.

# 1) Decompress the downloaded image
gunzip batocera-x86_64_v3-43.img.gz

# 2) Identify the target disk FIRST. Find the stick by its size.
lsblk
# NAME   SIZE TYPE MOUNTPOINT
# sda    465G disk           <- system drive, DO NOT TOUCH
# sdb     29G disk           <- the 32GB USB stick you just inserted

# 3) Write it. Replace sdb with YOUR device. No partition number.
sudo dd if=batocera-x86_64_v3-43.img of=/dev/sdb bs=64M status=progress conv=fsync
sync

What a successful flash looks like

When dd finishes it reports the bytes written and the throughput; balenaEtcher shows a green “Flash Complete” after its validation pass. Either way, the stick now carries two partitions — a small FAT boot volume labelled BATOCERA and the data volume — and Windows may pop up offering to format the second one. Decline that offer. Windows cannot read the Linux data partition and is merely confused; formatting it undoes your flash.

First Boot & Configuration

The first boot is where Batocera turns a flashed stick into a console. It expands storage, generates its configuration, and drops you at EmulationStation. Give it a minute of patience and a controller, and the rest is menus.

Let it expand, then map a pad

On the very first boot Batocera resizes userdata to occupy the entire drive, which is why a 32 GB stick reports 32 GB of space and not the 8 GB you wrote. When the theme loads, hold any button on your controller; the input wizard walks you through every axis and button. Assign a hotkey — usually the Guide or Select button — because Hotkey + Start is how you quit a game, and Hotkey + B and friends drive save states and menus. Skipping this leaves you trapped in the first game you launch, hunting for a keyboard.

Getting on the network and into a shell

Wired Ethernet needs no setup. For Wi-Fi, open Main Menu → Network Settings, enable Wi-Fi, and enter your SSID and key. Batocera exposes two doors for file transfer and administration: a Samba share and SSH. The default SSH login is user root, password linux — change it if the machine faces anything hostile. The wiki's SSH access page covers key-based logins and WinSCP for SFTP if you prefer a graphical file mover.

# From another machine on the same LAN:
ssh root@BATOCERA.local        # password: linux

# Confirm you are on the 43.x kernel line
uname -r
6.15.11

# userdata auto-expanded on first boot to fill the drive
df -h /userdata
# Filesystem      Size  Used Avail Use% Mounted on
# /dev/sdb2        28G  8.1G   20G  29% /userdata

Where settings live: batocera.conf

Almost every machine-wide setting lives in a single file, /userdata/system/batocera.conf, in a flat key=value format. You can edit it from the front-end, over SSH, or from another PC via the network share. The syntax is documented on the batocera-settings wiki page. A useful quirk to know early: after you set wifi.key in plain text and reboot, Batocera replaces the value with an encrypted enc:xxxxx token. That is expected, not a bug; you can overwrite it with clear text again and it will re-encrypt on the next boot. Special characters in an SSID or password must be escaped with a backslash.

Adding Games & BIOS

Batocera ships empty, so this is where the machine becomes yours. Two categories of files matter — games (ROMs and disc images) and the BIOS/firmware some systems require — and each has a specific home in the folder tree. Get the folders right and everything appears; get them wrong and you will stare at a menu that swears you own nothing.

The folder structure that makes systems appear

Over the network the machine presents itself as \\BATOCERA\share on Windows and macOS, or smb://BATOCERA.local/share on Linux — and if hostname discovery fails, \\192.168.1.X\share with the IP shown under Network Settings. Inside share the important directories are roms/, bios/, saves/, and system/. Games go into a per-system subfolder named by its shortname: SNES titles into roms/snes, Mega Drive into roms/megadrive, PlayStation into roms/psx, and so on. Each of those folders contains an _info.txt that lists the file extensions that system accepts, which is the fastest way to settle an “is this the right format” argument. The official add-games-and-BIOS wiki page is the authoritative reference for every shortname.

/userdata
├── roms/          # one subfolder per system shortname
│   ├── snes/
│   ├── megadrive/
│   ├── n64/
│   └── psx/
├── bios/          # BIOS / firmware live here
├── saves/         # in-game saves and save states
└── system/        # batocera.conf and all machine settings

BIOS files, checksums, and the law

Some systems — PlayStation, Sega CD, various handhelds — will not launch without their original BIOS, and Batocera cannot legally include one. Those files go in /userdata/bios/, and the emulator checks them against an expected md5 hash: a BIOS with the right name but the wrong dump will be rejected. The front-end has a built-in BIOS checker that lists exactly which files are missing or mismatched, and the libretro BIOS documentation is the canonical list of filenames and hashes. As for sourcing games at all: the operating system is free and legal, but ROMs and BIOS files are copyrighted works, and dumping cartridges you own is a very different legal posture from downloading a pre-filled image. If you want the full argument about what a curated, legally-grey library actually looks like, we walked through it in our breakdown of the Miyoo Mini Plus “game list”. Batocera stays clean by shipping none of it; the rest is on you.

Making new games show up

Copy files while EmulationStation is running and it will not notice them until told. After a transfer, refresh the library from Main Menu → Game Settings → Update Gamelists — press START to open the menu — and then run the scraper if you want box art, descriptions, and video previews. A freshly populated system only appears in the carousel after this refresh, which is the single most common reason a beginner insists their games “disappeared.” They did not; the list is stale.

# A populated SNES folder, seen over SSH
ls /userdata/roms/snes
_info.txt   Chrono Trigger (USA).sfc   Super Metroid (USA, Europe).sfc

# The _info.txt tells you which extensions this system accepts
cat /userdata/roms/snes/_info.txt
# Accepted extensions: .smc .sfc .swc .fig .bs .st .7z .zip ...

Common Pitfalls & Fixes

Almost every Batocera failure is one of a handful of mistakes, repeated forever across forums. Learn them once here and you skip the ritual of discovering each the hard way.

Flashing and booting mistakes

Pitfall 1 — Rufus in the wrong mode. Rufus defaults to ISO mode, which corrupts a raw .img. Fix: select DD Image mode, or use balenaEtcher, which has no such trap. Pitfall 2 — writing to a partition instead of the disk. Running dd of=/dev/sdb1 (a partition) instead of /dev/sdb (the whole disk) produces a stick that will not boot. Fix: always target the bare device node. Pitfall 3 — the machine boots Windows anyway. Secure Boot or a stubborn boot order is ignoring your stick. Fix: disable Secure Boot in firmware and use the one-time boot menu (often F12) to pick the USB.

Hardware and storage mistakes

Pitfall 4 — the wrong image for the CPU. The x86_64-v3 image will not boot on a pre-2013 processor and fails in a way that looks like a bad download. Fix: use the legacy x86_64 image on old hardware. Pitfall 5 — undersized media. A sub-16 GB stick disables auto-updates and leaves userdata cramped. Fix: use 32 GB or larger, USB 3.0 for speed. On an Nvidia GPU, remember the v3 image treats the driver as experimental — lean on integrated Intel/AMD graphics if you hit a black screen.

Content and upgrade mistakes

Pitfall 6 — ROMs in the wrong place. Files dropped in the root of share or the boot partition are invisible; they must live in roms/[shortname]. Fix: match the folder to the system and re-run Update Gamelists. Pitfall 7 — expecting BIOS to be bundled. It never is. Fix: supply the correctly-hashed files yourself and use the built-in BIOS checker. Pitfall 8 — losing DS saves on upgrade. Batocera 43 removed the DraStic emulator in favour of melonDS, and DraStic save states do not transfer. Fix: finish anything mid-save on the old core before upgrading, and expect to rebuild DS saves afterward. The same v43 cleanup also requires decrypted 3DS ROMs and renamed Azahar cores — upgraders should skim the changelog, not assume.

Troubleshooting Table

When something specific breaks, work from symptom to cause to fix. The table below covers the failures that fill support channels; most trace back to the pitfalls above, but a few are genuine 43-era quirks that 43.1 addressed.

Reading the table

Match the left column to what you actually see, not what you assume is wrong. A “black screen” and a “won't boot” are different problems with different fixes, and guessing wastes reflashes. Where a row references a fix that landed in 43.1, updating is the cleanest route.

Advanced Tips

Once the basics work, Batocera rewards tinkering. None of the following is required for a working setup, but each solves a real problem the moment you outgrow the defaults.

Manual and branch upgrades

The front-end's built-in updater handles the common case, but two situations call for doing it by hand. First, if a machine has no network or the auto-updater stalls, you can perform a manual upgrade by dropping a boot.tar.xz onto the boot partition per the manual-upgrade wiki page; a full o2switch mirror hosts the files if the primary is slow. Second, if you want to ride the bleeding edge, set the update channel in batocera.conf — updates.type=beta pulls pre-release builds, updates.type=stable keeps you on releases like 43.1. Beta is where new emulator work lands first and where new bugs land first; choose accordingly.

Per-game overrides and the config hierarchy

Batocera resolves settings from most specific to least: a per-game override beats a per-system setting, which beats the global default. That means you can force one troublesome title onto a different core, enable a shader for a single system, or turn on integer scaling everywhere without touching individual games. Bezels and decorations frame 4:3 content on a 16:9 panel; shaders emulate CRT scanlines if that is your taste. If you care about tearing during all this scaling, the relationship between V-Sync, frame caps, and variable refresh is worth understanding — we untangled it in our piece on G-Sync versus FreeSync, and the same logic applies to an emulator's output.

# /userdata/system/batocera.conf — per-system core and behaviour overrides
snes.emulator=libretro
snes.core=snes9x
n64.emulator=libretro
n64.core=parallel_n64        # more forgiving than mupen64plus-next on many titles
psx.core=swanstation
global.smooth=1              # bilinear smoothing on for every system...
snes.smooth=0               # ...but sharp pixels for the SNES specifically
global.rewind=0             # rewind off globally (it costs performance)

Bulk transfers, RetroAchievements, and netplay

For large libraries, copying over the Samba share works but SSH plus rsync is faster and resumable; WinSCP gives you the same over a GUI. If you want a reason to replay everything, enable RetroAchievements globally with your account credentials and the supported cores will track unlocks in the background. Netplay and Steam/ports round out the feature set, but treat them as extras — get a stable single-player library first, then expand.

The Complete Configuration

Here is a full, working batocera.conf baseline for a 43.1 machine, annotated so you can strip out what you do not need. Drop it in /userdata/system/batocera.conf, adjust the Wi-Fi, timezone, and account lines, and reboot. Every key here is documented on the wiki; when in doubt, cross-reference the settings reference rather than trusting a single example — including this one.

A sane batocera.conf baseline

# /userdata/system/batocera.conf  —  a sane 43.1 baseline

# ---- system ----
system.hostname=BATOCERA
system.language=en_US
system.timezone=America/New_York

# ---- updates ----
updates.enabled=1
updates.type=stable          # or 'beta' for pre-release builds

# ---- network / wifi (key becomes enc:xxxx after first reboot) ----
wifi.enabled=1
wifi.ssid=YourNetwork
wifi.key=YourWiFiPassword    # escape special characters with a backslash

# ---- audio ----
audio.volume=90

# ---- global emulator behaviour ----
global.retroachievements=1
global.retroachievements.username=YourRAName
global.smooth=1
global.rewind=0
global.integerscale=0
global.shaderset=none
global.bezel=default

# ---- controllers ----
controllers.bluetooth.enabled=1

# ---- per-system cores ----
nes.core=fceumm
snes.core=snes9x
megadrive.core=genesisplusgx
n64.emulator=libretro
n64.core=parallel_n64
psx.core=swanstation

The directory layout, one more time

If you remember nothing else, remember where files live. Games in /userdata/roms/[shortname]. BIOS in /userdata/bios/. Saves in /userdata/saves/. Settings in /userdata/system/batocera.conf. Everything you create is inside /userdata, and nothing you do can touch the read-only system or the Windows install on the internal drive. That containment is the entire promise of the distribution.

The final checklist

You are done when: the machine boots to EmulationStation from the stick; your controller is mapped with a working hotkey; the network share is reachable; at least one system shows games after an Update Gamelists; and any BIOS-dependent systems pass the built-in checker. Hit all five and you have a console that cost you a mini PC, a USB stick, and thirty minutes — running an operating system that has been free, open, and quietly excellent since 2016. Reflash any time; your userdata is the only thing worth backing up, and the OS you can always download again from batocera.org.