Batocera 43.1 Download & Flash: 12 Steps in 30 Min

There is a particular species of software that does not want to be your friend. It has no onboarding wizard with a cartoon mascot, it does not ask for your email, and it will cheerfully rearrange the boot order of a machine you paid good money for. Batocera.linux is that software, and it is one of the best things to happen to retro gaming precisely because it refuses to behave like a product.

This guide covers the Batocera download and install for the current stable release, version 43.1 'Glasswing', which shipped on 30 May 2026 as a bug-fix update to the 43.0 release from 8 May 2026. It is free, it is open source, and it runs from a stick without touching whatever operating system is already on your drive. What follows is the whole path: prerequisites with real version numbers, a twelve-step install you can finish in roughly thirty minutes, five ways people set their evening on fire, a troubleshooting table, and a complete working configuration you can paste in and forget. No fluff, because Batocera does not deal in fluff.

What Batocera Actually Is

Before you download anything, understand what you are downloading. Most people misfile Batocera in their heads as 'an emulator' or 'an app', and that misfiling is the source of about half the questions in every forum thread. It is neither. It is a Linux distribution whose entire reason to exist is to turn a computer into a games console and then get out of the way.

A distribution, not an app

Batocera is a self-contained operating system built on Buildroot, shipping the Linux kernel, an EmulationStation front end, and a large pile of preconfigured emulator cores, many of them from the libretro project that also powers RetroArch. You do not install it into Windows the way you install a program. You write the whole image to a USB stick or SD card, and the machine boots that image instead of its normal OS. It supports more than 200 systems out of the box, from the Atari 2600 and the NES at the trivial end up to PS2, GameCube, and even PS3 on hardware with enough muscle to keep up.

It eats your boot process, not your OS

This is the point people miss and then panic about. Batocera replaces the computer's boot process entirely and runs directly off the removable media, carrying only Linux and its emulator cores. Pull the stick out and your original Windows, macOS, or Linux install is exactly where you left it, untouched. That is a deliberate design choice, not an accident: it means an old laptop, a spare PC, or a handheld can moonlight as a console and go back to its day job the moment you unplug it. If you have wrestled with a frozen, single-purpose image before, this flexibility is the whole appeal; it is also why Batocera ships an x86 image at all, unlike the perennially frozen-at-v4.8 state of RetroPie on the PC.

Free, open source, and legally particular

Batocera is 100% open source and completely free. There is nothing to buy, and every line lives in the public GitHub repository at github.com/batocera-linux/batocera.linux. The project originates from France and, per its DistroWatch listing, is categorized under Gaming with aarch64 support and an Openbox desktop underneath the EmulationStation shell. One detail The Machine will not let you skip: the project copyright is held by Batocera.linux under a CC-BY-NC-SA license spanning 2016 to 2026. The NC stands for non-commercial. That is why the people selling 'loaded' SD cards on auction sites are standing on thin ice twice over: once on the ROMs they have no right to distribute, and once on the license of the distribution itself.

Prerequisites and the 32 GB Rule

Downloads fail for boring reasons. You picked the wrong image for your CPU, or you used a card that is too small, or you used a flashing method that does not actually write a bootable image. Sort the prerequisites first and the rest of this is mechanical.

The storage floor moved to 32 GB

For 43.1, you must use a 32 GB or larger USB drive or SD card. The old 16 GB minimum is now officially insufficient, and the reason is specific: the in-place automatic updater needs headroom to stage a new build alongside the running one, and 16 GB no longer leaves enough. A 16 GB card will flash and even boot, and then it will fail the first time it tries to update, which is a maddening way to learn the lesson. Buy a reputable 32 GB or 64 GB card rated Class 10 / A1 or A2. Cheap no-name cards are the single most common cause of corruption complaints that get blamed on the software.

Which machine: x86_64-v3, ARM, or Raspberry Pi

Batocera's headline feature in 43.0 was support for handhelds with AMD and Intel graphics on the preferred x86_64-v3 image. That microarchitecture level is not marketing; it requires a CPU with AVX2, which in practice means Intel Haswell or AMD Zen and newer, i.e. roughly 2013 onward. If your target machine predates that, the x86_64-v3 image will refuse to run and you want the plain x86_64 image instead. ARM single-board computers and handhelds use aarch64 images, and the Raspberry Pi 4 and 5 have their own dedicated builds. If you are eyeing an ARM handheld for this, the same silicon that matters for Android retro devices matters here; our breakdown of the Retroid Pocket 6 versus 5 and its 70% CPU jump is a useful primer on how much headroom PS2-class emulation actually demands.

Software you need before you start

You need exactly three things on the desktop side: the image, a way to verify it, and a flasher. For flashing, the officially recommended tools are balenaEtcher, Raspberry Pi Imager, or USBImager, and that recommendation is consistent across 43.0 and 43.1. Any of the three writes a raw image and verifies the write; do not drag the .img file into a file manager and expect a bootable stick, because that copies a file, it does not write an image. A second, larger USB stick is optional but handy if you plan to feed ROMs over USB rather than the network, and a controller of some kind is effectively mandatory because EmulationStation is built to be driven by a gamepad.

Downloading the Right Image

There is exactly one place you should be getting this from, and it is not a torrent aggregator or a YouTube description link.

The one true download page

The official portal is batocera.org/download. Everything current 43.1 image lives there, sorted by architecture. Pick your platform, and the page hands you a compressed image, typically a .img.gz. Do not decompress it manually unless a tool specifically demands a raw .img; balenaEtcher, Raspberry Pi Imager, and USBImager all read the .gz directly and decompress on the fly while writing, which is faster and uses less disk.

Matching image to silicon

Get this right and the install is a formality; get it wrong and you will spend an hour convinced your USB port is broken. For a modern PC or an AMD/Intel handheld, take x86_64-v3. For anything pre-2013, take plain x86_64. For a Raspberry Pi, take the Pi build that matches your board. For an ARM handheld, take the aarch64 build listed for your device family. When in doubt, the device-specific pages on the official wiki spell out exactly which image maps to which board, and that mapping is worth thirty seconds of reading.

Verifying the download

A retro-gaming image is a couple of gigabytes, and a couple of gigabytes is exactly the size that gets silently truncated on a flaky connection. The symptom of a bad download is not an error, it is a flash that completes and a first boot that hangs halfway, which sends you chasing hardware ghosts. Verify the checksum before you flash.

# Verify the download against the hash printed on the download page
sha256sum batocera-x86_64-v3-43.1-20260530.img.gz

# Expected: a hex string that matches batocera.org character-for-character
# 9f2c1e...a41b  batocera-x86_64-v3-43.1-20260530.img.gz

# Flashers read the .gz directly; decompress only if a tool demands a raw .img
gunzip -k batocera-x86_64-v3-43.1-20260530.img.gz

The hash above is illustrative; the real value is whatever the download page prints next to your file. If it does not match character-for-character, delete the file and download again. This one habit prevents more support tickets than any other.

The Full Install in 12 Steps

The official guidance frames a complete, secure setup for 43.1 as twelve specific steps taking around thirty minutes end to end. Here they are, each with the reason it exists, because a step without a rationale is just a superstition you repeat.

What the 30 minutes actually buys

Thirty minutes is realistic if your ROMs and BIOS are already gathered and your network is up. The download and the flash eat most of the clock; the configuration itself is fast once you know where things live. Do not rush steps 9 through 11, because those are the ones people skip and then regret.

1. Download the matching image from batocera.org/download. Architecture mismatch is the number one reason a fresh install never boots, so confirm x86_64-v3 versus x86_64 versus ARM before anything else.
2. Verify the SHA-256 checksum. A truncated download flashes a stick that fails partway through first boot and looks exactly like a hardware fault. Thirty seconds here saves an hour later.
3. Insert a 32 GB or larger USB stick or SD card. 43.1's in-place updater needs the headroom; 16 GB media can flash but chokes the first time it tries to update itself.
4. Flash with balenaEtcher, Raspberry Pi Imager, or USBImager. These write raw images and verify the result. Copying the .img in a file manager produces a stick full of nothing bootable.
5. Set the machine to boot from the stick. Batocera replaces the boot process, so if firmware still points at the internal drive you will boot your old OS and swear the flash failed. Use the one-time boot menu (usually F12, F11, or Esc) or set USB first in firmware.
6. Let the first boot expand the partition. Batocera grows its userdata / SHARE partition to fill the media on that first run. Interrupting it mid-expand corrupts the filesystem, so leave it alone until it settles at the menu.
7. Choose language and connect to the network. Scraping artwork, downloading updates, and copying ROMs over the network all need connectivity, and wired Ethernet is more reliable than Wi-Fi for the first run.
8. Pair your controller. EmulationStation is gamepad-driven; map the controller once at this screen and every emulator inherits the mapping automatically.
9. Change the default root password and review Security. The box ships as user root with password linux and SSH open. On any shared network, that default is an open door, so close it now, not later.
10. Copy ROMs into /userdata/roms/[system]. Batocera ships zero games. The folder name is the system id, and putting a SNES ROM in the wrong folder produces an empty list and a confused user.
11. Place BIOS and firmware into /userdata/bios and check MISSING BIOS. PS1, PS2, and several others silently bounce back to the menu without the exact, hash-matched files. The built-in checker tells you precisely what is absent.
12. Update game lists, scrape, and reboot once. A clean reboot commits the overlay and rebuilds the gamelist so everything you added actually appears. Skipping this is why 'my games are not showing up' is the most common last-mile complaint.

Expected result after step 12

After the reboot you should land on the EmulationStation carousel showing only the systems for which you supplied at least one ROM. Empty systems are hidden by default, which is a feature, not a bug: a clean menu means your ROM folders are named correctly. If you see systems you did not populate, or you do not see systems you did, jump to the troubleshooting table.

If a step fails

Almost every failure in this sequence traces back to steps 1, 3, or 5: wrong image, undersized card, or wrong boot device. Before you assume something exotic, re-check those three. The exotic explanation is real maybe one time in twenty.

First Boot Configuration

The first boot is where Batocera quietly does the work that makes everything else possible. Understanding what it is doing keeps you from interrupting it at the worst moment.

Partition auto-expansion

On that first boot, Batocera resizes its data partition to fill the entire card or stick. On a 64 GB card, that means the userdata area balloons from a couple of gigabytes to nearly the whole device, which is where your ROMs, saves, screenshots, and configuration will live. This takes anywhere from a few seconds to a minute or two depending on the media, and the machine may appear to sit still while it happens. Do not pull power. An interrupted expand is the classic way to corrupt a fresh install and generate a bug report that is really a user error.

Getting online

Wired Ethernet needs no configuration; plug it in and it works. For Wi-Fi, you can set it in the menu, or you can pre-seed it in the main configuration file, which is handy if you are provisioning several machines.

## /userdata/system/batocera.conf  -- Wi-Fi lines
wifi.enabled=1
wifi.ssid=YourNetworkName
wifi.key=YourNetworkPassword

## Save and reboot to apply. Ethernet needs no config at all.

If no networks appear at all, the usual culprit is a Wi-Fi adapter whose firmware Batocera does not carry, or a 5 GHz-only radio. A cheap known-good USB Wi-Fi dongle or a run of Ethernet solves it faster than fighting the driver.

Controllers and hotkeys

Batocera auto-detects most controllers, including Xbox, PlayStation, and 8BitDo pads. The one concept worth internalizing is the hotkey: by default it is the Select button, and Select combined with Start exits a game, Select combined with the shoulder buttons saves and loads states, and so on. Map your controller once at the input screen and that mapping propagates to every emulator, which is exactly the kind of thing you would have to configure per-emulator in a lesser setup.

Adding ROMs and BIOS

This is the part the download page cannot do for you, and the part the law has opinions about. Batocera ships Linux and cores and precisely zero games or BIOS files. You supply those.

The /userdata/roms tree

The easiest transfer method is the network share. Once Batocera is online, it advertises itself on the local network, and you can reach it from Windows at the address BATOCERA over SMB, or from macOS and Linux the same way. Drop each system's games into its matching folder. The folder name is the system identifier, and it must match exactly.

/userdata
|-- roms
|   |-- nes/        (.nes .zip)
|   |-- snes/       (.sfc .smc .zip)
|   |-- megadrive/  (.md .bin .zip)
|   |-- psx/        (.chd .pbp .cue+.bin)
|   |-- ps2/        (.iso .chd)
|   +-- gc/         (.rvz .iso)
|-- bios/           (BIOS + firmware, hash-checked)
|-- saves/
+-- system/
    +-- batocera.conf

For disc-based systems, prefer the CHD or RVZ formats over raw ISO or BIN: they compress losslessly, they are widely supported, and they cut the storage bill dramatically. A shelf of PS1 games in CHD is a fraction of the size of the same games as CUE+BIN.

BIOS files and why emulators refuse to boot

Some systems will not run without their original firmware. PlayStation, PlayStation 2, and a handful of others need specific BIOS files placed in /userdata/bios, and Batocera checks them by hash. If the file is wrong by a single byte, the emulator loads, then silently drops you back to the menu, which reads as a crash but is actually a polite refusal. The built-in checker tells you exactly what is missing and expected.

MAIN MENU > GAME SETTINGS > MISSING BIOS

system   file             status     md5
psx      scph5501.bin     MISSING    490f4...
ps2      ps2-0230a.bin    FOUND      ...
gc       IPL.bin          OPTIONAL   -

The legal part, because you knew it was coming

The Machine is contractually obligated to remind you: dumping games and BIOS from hardware you own is a different animal from downloading them, and Batocera ships neither on purpose. That absence is not an oversight, it is the reason the project can exist as free, open-source software under CC-BY-NC-SA without inviting a lawsuit. If you want a curated, self-contained library instead of assembling your own, that is a different product category with different tradeoffs; our look at the Miyoo Mini Plus and its 6,041-ROM aggregation walks through what 'preloaded' actually means and why no official catalog stands behind those numbers.

Securing SSH and the Web UI

Batocera is built for convenience on a trusted home network, which means its defaults are wide open. On a dorm network, a shared flat, or anywhere else, those defaults are a liability you should close in the first five minutes.

Change the root password first

The distribution ships with a single account, root, and a default password of linux, with SSH enabled out of the box. Anyone on the same network who knows Batocera knows those credentials. Change the password immediately, either through System Settings and the Security menu in EmulationStation, or over SSH directly.

# From your desktop, install your SSH key (default password is linux):
ssh-copy-id root@192.168.1.42

# Log in and change the default password immediately:
ssh root@192.168.1.42
passwd

# Persist changes that live outside /userdata:
batocera-save-overlay

Key-based SSH

Password auth is fine for a locked-down home LAN, but keys are better and take one command to set up, as above. Once your public key is in place, you get passwordless login and you can, if you like, turn password auth off entirely. When you log in successfully, you should see something close to this:

$ ssh root@192.168.1.42
Password:
=========================================
  Batocera.linux 43.1  (Glasswing)
  the retro-gaming distribution
=========================================
[root@BATOCERA ~]#

Turn off what you do not use

Batocera exposes a web UI on port 80 for managing the box from a browser, which is convenient and also another open surface. If you never use it, there is no reason to leave it reachable. The important habit here is batocera-save-overlay: the root filesystem is read-only by design, and system-level changes made over SSH will evaporate on reboot unless you commit them to the persistent overlay. Anything you write under /userdata persists automatically; anything outside it does not until you save the overlay.

Updating: Menu vs SSH

The whole reason for the 32 GB storage floor is so that updates are a menu click rather than a reflash. There are two ways to do it, and both are painless.

The in-menu path

From the front end, the path is MAIN MENU > UPDATES and DOWNLOADS > START UPDATE. Batocera checks the mirror, downloads the new build, stages it, and prompts you to reboot into it. Because it stages the new version alongside the running one, an update that fails or gets interrupted leaves the working system intact, which is exactly why the extra storage matters.

The SSH one-liner

If you live in a terminal, the same job is one command against the mirror, followed by a reboot.

# SSH in, then run the upgrade against the French o2switch mirror:
batocera-upgrade https://mirrors.o2switch.fr/x86_64/stable/last

# Expected output:
#   Checking latest version ...
#   Downloading boot.tar.xz  [==========] 100%
#   Update ready. Please reboot.
reboot

That mirror is mirrors.o2switch.fr, hosted by o2switch, a French provider, which is a small tell that this is a French project through and through. Swap the x86_64 path segment for your own architecture if you are on ARM or a Pi.

Pinning and rolling back

Batocera runs update channels: stable is what you want for a set-and-forget box, and the bleeding-edge channel exists for people who enjoy filing bug reports. 43.1 landing as a bug-fix over 43.0 within a month is the stable channel working exactly as intended. If an update ever misbehaves, the cleanest rollback is to reflash the previous image to the card, since your ROMs and saves live in userdata and can be preserved separately. Keep a backup of /userdata/system before any major version jump and you will never lose a configuration to an update.

Five Common Pitfalls

Every one of these is avoidable, and every one of these will eat an evening if you walk into it blind. The Machine has watched all five happen more times than it cares to count.

Storage, architecture, and boot order

• The 16 GB card. Symptom: flashes fine, boots fine, then every update fails or reports no space. Fix: reflash to a 32 GB or larger card. This is the single most common 43.1 mistake because the old advice said 16 GB was enough and a lot of it is still floating around.
• Wrong architecture. Symptom: instant reboot loop or an illegal-instruction fault on a pre-2013 PC. Cause: you flashed x86_64-v3 onto a CPU without AVX2. Fix: reflash the plain x86_64 image. The v3 build is faster where it runs, but it simply will not run on older silicon.
• Expecting a dual-boot menu. Symptom: the machine boots straight into Windows and you conclude the flash failed. Cause: Batocera runs from the stick and does not install a bootloader onto your drive. Fix: use the firmware one-time boot menu to pick the USB device, and if it still will not appear, disable Secure Boot.

BIOS and persistence

• BIOS in the wrong place or with the wrong hash. Symptom: an emulator loads and immediately dumps you back to the menu. Cause: missing or byte-wrong firmware. Fix: put files in /userdata/bios and consult MAIN MENU > GAME SETTINGS > MISSING BIOS, which names exactly what it wants.
• Forgetting batocera-save-overlay. Symptom: a system tweak you made over SSH is gone after reboot. Cause: the root filesystem is read-only and changes outside /userdata are not persisted until you commit them. Fix: run batocera-save-overlay before rebooting. Anything under /userdata is safe automatically; anything else is not.

The security default

The sixth pitfall, because five was never going to be enough for a distribution this open: leaving root as password linux with SSH exposed. It is not a problem until it is, and then it is a big one. Change it during the install, not after an incident.

Troubleshooting Table

Keep this near the machine during your first hour. Most first-day problems are on it.

Advanced Tips

Once the basics work, Batocera has depth the wiki buries under a hundred pages. Here is where the real quality-of-life gains live.

Cores, and what changed in 42 and 43

Batocera lets you pick emulator cores per system, which matters because the default is not always the best fit for your hardware. For SNES, snes9x is fast and accurate enough for almost everyone, while bsnes chases perfect accuracy at a higher cost. For N64, mupen64plus_next is the sensible default. Recent releases moved several standalone ports forward: version 42 migrated the Quake engine to vkQuake, covering Quake 1, 2, and 3, and replaced OpenLara with the standalone TR1X engine for Tomb Raider. Version 43 tightened others: the TheXTech core now requires a minimum of 1.3.7 assets, and the 3DS side swapped the Azahar Plus project for the upstream source project, Azahar. If a port that worked before suddenly complains, an asset or core rename from these changelogs is usually why.

## Per-system core selection (batocera.conf)
snes.core=snes9x
n64.core=mupen64plus_next
psx.core=swanstation

## Global look and feel
global.smooth=0
global.shaderset=none
global.bezel=none
global.integerscale=1
global.rewind=1

## Per-GAME overrides: name a .cfg to match the ROM in the same folder.

Shaders, bezels, and integer scaling

The purists among us turn off bilinear smoothing (global.smooth=0), enable integer scaling so pixels stay square, and apply a CRT shader to taste. The shader and decoration systems are inherited from RetroArch, and the RetroArch documentation plus the libretro core docs are the authoritative references for what each option actually does. Bezels (decorations) fill the dead space on a 16:9 display around a 4:3 game with artwork instead of black bars, and they are the fastest way to make the whole setup look intentional rather than improvised.

Per-game overrides and collections

Global settings are a starting point, not a straitjacket. You can override any setting per system, and per individual game, so that the one title that needs a different core or a specific resolution gets it without disturbing everything else. Collections and favorites let you build custom carousels, which is where a large library stops being a chore to navigate. If you are choosing hardware to run all this, the same performance thinking applies as in our 2026 Retroid Pocket handheld roundup: the ceiling on what you can emulate is set by silicon, and Batocera will happily expose that ceiling.

A Complete batocera.conf

Here is a working baseline you can drop into /userdata/system/batocera.conf, edit for your network and taste, and reboot into. It assumes 43.1, sets sane global defaults, picks solid cores, and stays on the stable update channel. The authoritative key reference is the wiki; this is a sensible starting point, not the last word.

## /userdata/system/batocera.conf
## Batocera 43.1 'Glasswing' - working baseline
## Full key reference: wiki.batocera.org

# --- System ---
system.hostname=BATOCERA
system.language=en_US
system.kblayout=us
system.timezone=Europe/Paris
audio.volume=90

# --- Network (skip if wired) ---
wifi.enabled=1
wifi.ssid=YourNetworkName
wifi.key=YourNetworkPassword

# --- Updates ---
updates.enabled=1
updates.type=stable

# --- Global emulator defaults ---
global.smooth=0
global.shaderset=none
global.bezel=none
global.integerscale=1
global.ratio=auto
global.rewind=1
global.retroachievements=0

# --- Per-system overrides ---
nes.core=fceumm
snes.core=snes9x
megadrive.core=genesisplusgx
n64.core=mupen64plus_next
psx.core=swanstation
ps2.emulator=pcsx2
gc.emulator=dolphin

Save it, run batocera-save-overlay if you edited it over SSH, and reboot once. That single reboot is what turns a pile of settings into a working console. From here the loop is simple: add ROMs to /userdata/roms, hash-match BIOS into /userdata/bios, scrape metadata, and let the in-menu updater keep 43.1 current. It is free, it is open source, it runs 200-plus systems off a stick that costs less than lunch, and it never once asks for your email. That is the whole pitch, and Batocera has never needed a better one.