Batocera 43.1 Download: 12 Steps, 30 Min, 200 Systems

There is a specific kind of person who types batocera download into a search box, and there is a specific kind of website waiting for them: the machine-spun '12 Steps ' blog post that rewrites the official wiki, pads it with stock photos of arcade cabinets, and points you at a 'mirror' that is not a mirror. This is not that article. This is the actual procedure for getting Batocera onto a drive and booting it, written by someone who has done it enough times to know precisely where it goes sideways.

Batocera 43 shipped on 8 May 2026 under the codename Glasswing. The 43.1 point release followed on 30 May 2026 and is what you will pull from the download page today. It is free, it is open source, it costs exactly nothing, and it does not ship with a single game. Everything below assumes you have made peace with those three facts. Budget roughly thirty minutes, most of which is the flash writing to a stick and the first boot silently resizing a partition while you make coffee.

One structural thing before we start: Batocera is not an app. It is a full Linux operating system that boots straight into an emulator front-end. That distinction changes every decision you are about to make, so we start there.

What Batocera 43.1 Actually Is

People conflate three different things under the word 'emulator front-end,' and the confusion causes half the failed installs on the forums. Batocera occupies a very particular slot in that lineup, and if you understand the slot, the rest of the tutorial stops surprising you.

An operating system, not a program

RetroArch is an application: you install it on top of Windows, macOS, Android, or Linux, and it runs libretro cores inside a window. EmuDeck is a script: it configures a pile of standalone emulators on top of SteamOS or Windows. Batocera is neither. It is a self-contained Linux distribution that takes over an entire block device and boots directly into EmulationStation with a few hundred emulator cores already wired up. There is no host OS underneath it doing the work. Batocera is the host OS.

The practical consequence: when you run Batocera from a USB stick, your Windows or Linux install on the internal disk is never touched, because the machine is booting an entirely different operating system off the stick. When you 'install to internal disk,' Batocera overwrites that disk completely. There is no in-between where Batocera lives 'inside' Windows as a folder. If you have used a manual RetroArch cores setup before, unlearn that mental model; Batocera bundles the cores for you and hides the plumbing.

What 'Glasswing' actually ships

Version 43 is not a cosmetic bump. Under the hood it moves to Linux kernel 6.18.16 and Mesa3D 25.3.6, and it introduces the LabWC 0.9.3 Wayland compositor on the new x86_64-v3 image aimed at handhelds with AMD or Intel graphics. On the emulator side, Glasswing pulls RPCS3 up to v0.0.40, PCSX2 to v2.6.3, Cemu to its 5 April 2026 build, libretro Dolphin to the 24 December 2025 build (with light-gun support), and melonDS to 1.1. New hardware targets in this cycle include the AYN Thor, the Retroid Pocket 6, the Odin 2 Mini, and the Anbernic RG28XX / RG34XX / RG35XX / RG40XX family, plus RTL8832CU and RTL8852CU USB Wi-Fi adapters on x86_64. The marketing line is '200+ systems,' and for once the marketing line is roughly accurate.

Stable versus Butterfly

Batocera publishes two branches. Stable is the numbered release line — 42, 43, 43.1 — and it is what you install unless you have a specific reason not to. Butterfly is the rolling beta where new emulator builds and hardware fixes land first, and where things also break first. The download page and the in-system updater both let you choose. If you are reading a tutorial on how to download Batocera, you want Stable. Switch to Butterfly only when a specific game needs a fix that has not reached a stable release yet, and even then, know that you are volunteering as a tester. The official Updates & Downloads wiki page spells out the branch differences if you want the long version.

Prerequisites: Drives, Hardware, Software

Half of the 'Batocera won't boot' threads are prerequisites problems in disguise: a stick that is too small, a CPU that is too old, or a flasher that mangled the image. Get these three categories right and the install is boring, which is the goal.

The target hardware

For the mainstream x86_64 image you want a 64-bit x86 CPU — any Intel or AMD part from roughly the last decade qualifies — with at least 4 GB of RAM. Batocera will run on less, but PlayStation 2, GameCube, Wii, and later systems lean hard on the GPU, so integrated graphics from the Haswell era will emulate an SNES flawlessly and choke on God of War. A cheap modern mini-PC with Vega or Xe integrated graphics is the sweet spot for a living-room build. You also need a game controller; almost any USB or Bluetooth pad is detected automatically, but a wired pad removes an entire class of first-boot pairing headaches.

If you are eyeing a handheld instead of a PC, Batocera has dedicated images for the Steam Deck, the Retroid Pocket 5 and 6, the Ayn Odin 2 and Thor, and the Anbernic RG line. Those are separate downloads and a separate discussion; if you are still shopping, our Retroid Pocket lineup breakdown and the MiSTer Multisystem 2 writeup cover the hardware end far more thoroughly than a download guide should.

The drive: 16 GB minimum, 32 GB in practice

This is the single most common mistake, so it gets bold text: the compressed x86_64 image is around 2.5 GB, and it expands to roughly 8 GB of image once written. The official wiki lists 16 GB as the minimum and 32 GB as the recommendation, and the reason for the gap is updates. When Batocera downloads a new release, it needs room to stage the incoming image alongside the running one. On an 8 GB stick, that fails; on a 16 GB stick, it is tight; on a 32 GB stick, you never think about it again. Buy a 32 GB USB 3.0 stick, or better, a small USB-attached SSD. USB 2.0 works but reads ROMs slowly. For a Raspberry Pi, use a Class 10 / A1-rated microSD or you will feel every menu.

The software on your main computer

You flash the image from whatever computer you already own. The Batocera wiki's primary recommendation is the Raspberry Pi Imager, which despite the name flashes any image to any drive and decompresses .img.gz on the fly. USBImager is a lighter alternative. balenaEtcher is popular and cross-platform but carries documented Windows quirks around drive detection, so treat it as the fallback rather than the default; grab it from etcher.balena.io if you go that route. You do not need anything else — no paid utility, no registration, no 'driver pack.' Anyone selling you those is selling you air.

Pick the Correct Image (Or Nothing Boots)

The download page at batocera.org/download is organized by hardware, and picking the wrong entry is the fastest way to a black screen. The categories look intimidating; they are not, once you know which two words describe your machine.

The x86_64 family

For a standard PC or mini-PC, you want x86_64. The page also offers a Zen3 / x86-64-v3 variant, which is compiled for newer CPUs (roughly AMD Zen 3 and recent Intel) and squeezes out a little extra performance on hardware that supports the v3 instruction set. If you are not certain your CPU is new enough, take the plain x86_64 image; it boots on everything 64-bit and the performance delta is marginal for anything short of PS3-class emulation. There is also a 32-bit legacy image for genuinely ancient hardware, which you should only reach for if the machine physically cannot run 64-bit code.

Raspberry Pi and ARM boards

The Pi images are model-specific down to the exact board. A Pi 4B image will not boot a Pi 5B and vice versa, because the bootloaders and device trees differ. The download page lists everything from the Pi Zero 2 W up through the Pi 5B; match your board exactly. The same discipline applies to the Rockchip, Amlogic, Odroid, Khadas, and OrangePi single-board categories — Batocera builds a tailored image per SoC, and 'close enough' does not boot.

Handhelds, and one that is not on the list

The handheld section carries first-class images for the Steam Deck, GPi Case, Odroid Go Ultra/Advance/Super, the Anbernic RG series, the Ayn Odin 2 and Thor, and the Retroid Pocket Mini, V2, 5, Flip 2, and 6. If your device is here, use the device-specific image rather than a generic one, because it ships the right kernel and controller mappings. Note what is not on the list: the Miyoo Mini Plus. That device runs the Onion firmware on an SSD202D chip that is far too weak for a full Linux distribution with hundreds of cores — the research briefs that claim Batocera runs on it are simply wrong. If you are choosing between that class of ultra-budget handheld and something Batocera actually supports, the Miyoo Mini Plus versus RG35XX comparison lays out why the chip matters more than the price.

The 12-Step Install Walkthrough

Here is the whole procedure, download to first boot, as twelve discrete steps. Each one includes the reason it exists, because a step without a rationale is just superstition, and the internet has enough of that.

1. Confirm the target drive is expendable. Flashing wipes the destination drive completely and without a confirmation dialog worth the name. Before you do anything, verify that the USB stick or disk you are about to write holds nothing you want. Rationale: dd and every GUI flasher will happily erase your photo backup if you point them at it.
2. Download the correct .img.gz from batocera.org/download. Use the architecture you settled on in the previous section — x86_64 for a normal PC. Rationale: the image is a raw disk image; the wrong architecture will not produce a boot error, it will produce nothing on screen, which is harder to diagnose.
3. Optionally verify the download. If the page publishes a checksum, or you simply want to be sure the ~2.5 GB file arrived intact, hash it before flashing. Rationale: a truncated or corrupted image is the single most common cause of a stick that flashes 'successfully' and then hangs at boot.
4. Install a flasher. Raspberry Pi Imager, USBImager, or balenaEtcher. Rationale: all three read .img.gz directly and decompress while writing, so you do not extract the archive by hand.
5. Select the image, then the target drive, in the flasher. In Raspberry Pi Imager: CHOOSE OS → 'Use custom' → pick the .img.gz; then CHOOSE STORAGE → select the stick. Rationale: choosing storage second forces you to look at the drive list and catch a wrong selection before it is fatal.
6. Write the image and wait. Click NEXT, decline the customization prompt, confirm, and let it run. On a USB 3.0 stick this is a few minutes. Rationale: interrupting a write leaves a half-formed image that boots to garbage.
7. Do not manually extract the .gz. Unless you are using dd deliberately, leave the archive compressed and let the flasher handle it. Rationale: people extract the image, then flash the archive anyway, or flash the extracted .img with a tool expecting .gz; both fail confusingly.
8. Move the drive to the target machine and power on. Rationale: obvious, but worth stating — the flashing computer and the gaming machine are usually different boxes.
9. Enter the boot menu and select the USB drive. On most PCs this is F10, F11, or F12 during power-on; the exact key is printed on the POST screen. Rationale: a PC defaults to booting its internal disk, so you must explicitly tell it to boot the stick this once.
10. If the drive does not appear, fix the firmware. Enter BIOS/UEFI (often Del or F2), disable Secure Boot, enable 'Removable Media Boot' / USB boot, and prefer UEFI mode. Rationale: Secure Boot rejects Batocera's bootloader, and it is the number-one reason a correctly flashed stick 'does not show up.'
11. Let the first boot expand the userdata partition — do not power off. On first run, Batocera grows its data partition to fill the drive, which can take a minute or two on a black or near-black screen. Rationale: pulling power here corrupts the partition table and forces a reflash.
12. Set your language and controller, then add ROMs. Once EmulationStation appears, map a controller, set your language, and copy games and BIOS files (next section). Rationale: an empty install boots to a front-end with almost nothing to launch; the games are your job.

For the command-line-inclined, steps 3 and 6 look like this. The verification is optional; the extraction is only needed if you intend to write with dd yourself.

# Optional integrity check before you flash (Linux/macOS)
sha256sum batocera-x86_64-43-20260530.img.gz

# Flashers read .gz directly, so you rarely need this, but to
# extract by hand while keeping the original archive:
gzip -dk batocera-x86_64-43-20260530.img.gz
ls -lh batocera-x86_64-43-20260530.img
# -rw-r--r-- 1 you you 7.9G  batocera-x86_64-43-20260530.img

If you prefer to skip the GUI entirely on Linux, you can stream the compressed image straight to the block device. Identify the disk first; getting the device node wrong here erases the wrong drive with no undo.

# Identify the target disk FIRST.
lsblk
# NAME   SIZE TYPE MOUNTPOINT
# sda   931G disk /            <-- your system disk, DO NOT TOUCH
# sdb  28.9G disk              <-- the 32GB USB stick

# Write the compressed image straight to the stick:
zcat batocera-x86_64-43-20260530.img.gz | sudo dd of=/dev/sdb bs=4M status=progress conv=fsync
sync

The full, architecture-by-architecture version of this procedure lives on the official Install Batocera wiki page, which is the canonical source and the thing every '12 steps' content farm quietly plagiarizes.

BIOS, Secure Boot & the Boot Menu

Step 9 and step 10 above are where a clean flash still refuses to boot, and the culprit is almost always firmware policy rather than the image. This section is the expanded troubleshooting for that moment when the stick is written correctly and the machine still boots into Windows.

The boot menu keys

Every motherboard exposes a one-time boot menu separate from the main firmware setup. On the majority of desktops and mini-PCs the key is F11 or F12; on many laptops it is F10 or F9; the POST splash usually prints it for a half-second. Tap it repeatedly as the machine powers on, and you should see a list of bootable devices. Your USB stick appears by its brand name or as a generic 'UEFI: USB' entry — pick the UEFI one when both a UEFI and a legacy entry exist, because Batocera 43 expects a UEFI boot on modern hardware.

Secure Boot and USB boot

If the stick is flashed but never shows in the boot menu, enter the full firmware setup (commonly Del or F2) and change three things. Disable Secure Boot, which otherwise refuses to load Batocera's unsigned bootloader. Enable Removable Media Boot or 'USB Boot' if your firmware lists it separately. And set the boot mode to UEFI rather than Legacy/CSM. Save and reboot into the boot menu. Nine times out of ten, Secure Boot was the wall. This is standard for any Linux-based live OS and is not unique to Batocera.

The batocera-boot.conf escape hatch

After flashing, the small first partition on the stick is a FAT filesystem that Windows and macOS can read directly. It contains batocera-boot.conf, an early-boot config you can edit from your main computer before you ever boot the target machine. The two settings people reach for most: forcing the proprietary NVIDIA driver on a discrete NVIDIA GPU that otherwise boots to a black screen, and pinning the console output to a specific display.

## /boot/batocera-boot.conf  (edit on the small FAT partition)
## Force the proprietary NVIDIA driver on supported GPUs:
nvidia-driver=true

## Pin output to a specific connector if the console lands on the wrong one:
# display.output=HDMI-1

Editing this file before first boot is the cleanest fix for the classic 'NVIDIA card, black screen after the boot logo' symptom, and it saves you from blind-typing commands into a display you cannot see.

Getting ROMs and BIOS Onto the Box

Batocera ships zero games and zero BIOS files, by design and by law. The distribution contains no copyrighted material, which is exactly why it can be given away freely. Supplying content is your responsibility, and the only unimpeachable source is media you own and dump yourself — our cartridge-dumping walkthrough covers doing that legally. Batocera gives you several transfer routes; here are the three that matter, documented in full on the Add games/BIOS wiki page.

The F1 file manager (local, no network)

On PC x86/x86_64, the Raspberry Pi 4, and the Retroid Pocket 5/Mini, pressing F1 from the EmulationStation system list opens a full graphical file manager. Plug in a second USB drive holding your files, navigate to it, right-click → Copy, then paste into the target folder under /userdata/roms/. Press F4 inside the manager for a terminal if you need one, and Ctrl+Q or the File menu to exit back to EmulationStation. After copying, rescan with START → GAME SETTINGS → UPDATE GAMELISTS, or the new games will not appear. This is the fastest method when the box is not on your network yet.

The network share (SMB)

Batocera enables a Samba share out of the box. From another computer on the same network you reach it at \\BATOCERA\share on Windows and macOS, or smb://BATOCERA.local/share on Linux. If the hostname does not resolve, use the device's IP address — find it under MAIN MENU → NETWORK SETTINGS → IP ADDRESS — as \\192.168.x.x\share. Inside the share you will find roms, bios, and saves folders; drag files straight in over the network. This is the least fiddly method for a headless living-room box.

SSH and SCP (scriptable)

SSH is enabled by default. The credentials are the well-known Batocera defaults — user root, password linux — and you should change them the moment the box is on a network you do not fully control, via MAIN MENU → SYSTEM SETTINGS → SECURITY. Note that no asterisks echo while you type the password; that is normal. The folder layout is worth memorizing:

ssh root@batocera.local
# password: linux  (nothing echoes as you type it)

# Where everything lives:
/userdata/
├── bios/                 # BIOS files go here (scph5501.bin, etc.)
├── roms/
│   ├── snes/             # one folder per system
│   ├── psx/
│   └── n64/
├── saves/                # save files and save states
└── system/
    ├── batocera.conf     # the master config file
    └── custom.sh         # a script that runs at boot

With that map, pushing files from your PC is a one-liner per system. Each ROM folder also contains an _info.txt listing the accepted file extensions for that emulator, which is the first thing to check when a game refuses to appear.

# Push a folder of SNES ROMs to the box:
scp -r ~/roms/snes/* root@batocera.local:/userdata/roms/snes/

# Push a PS1 BIOS file:
scp scph5501.bin root@batocera.local:/userdata/bios/

# Then, on Batocera: START -> GAME SETTINGS -> UPDATE GAMELISTS

The SSH access, key management, and how to disable guest login are all documented on the SSH wiki page. One warning that belongs here rather than in a footnote: ignore any site offering a paid 'members area' with bundled ROM and BIOS packs. The only official download is batocera.org, the software is free, and a subscription to a third-party archive is neither endorsed nor legal cover.

Installing to an Internal Disk

Running Batocera from a USB stick is the correct default: it is non-destructive, portable, and trivially reversible — pull the stick and your PC boots Windows again. But if you are building a dedicated console, committing Batocera to the machine's internal SSD is faster and tidier. This is a deliberate, destructive step, and Batocera treats it as one.

When to actually commit

Install to internal disk when the hardware will only ever be an emulation box, when you want faster ROM loading than a USB 2.0 stick provides, or when you are tired of leaving a stick protruding from a media-center PC. Do not do it on a machine you still use for anything else. There is no meaningful dual-boot story here; Batocera is happiest owning the whole disk.

The menu path and the warning

Boot Batocera from the USB stick as usual, then press START to open the menu and navigate to MAIN MENU → SYSTEM SETTINGS → INSTALL BATOCERA ON A NEW DISK. Select the internal target, confirm, and let it copy. The wiki's own warning is blunt and correct: 'all existing data on the target disk will be overwritten.' There is no partition-preserving option. Whatever was on that SSD — Windows, your files, a previous Linux install — is gone when this completes.

What carries over, and what does not

The internal install writes a fresh system; it does not migrate the ROMs and configuration from your USB stick automatically. Your games, saves, and batocera.conf live under /userdata, so plan to copy that content across afterward using the same SMB or SCP methods from the previous section. Think of the USB stick as the installer, and the internal disk as a blank slate you then populate.

Updating: Stable vs Butterfly

Batocera updates in place. You do not reflash to move from 43 to 43.1 or to the next release; the running system pulls and stages the new image and reboots into it, preserving /userdata. This is why the 32 GB drive recommendation exists — the updater needs headroom to stage the incoming build.

Updating from the interface

Press START and open UPDATES & DOWNLOADS. Set the Update Type to Stable (or Butterfly, if you have decided to live dangerously), run Check for Updates, and if one is available, Start Update. The system downloads, verifies, and reboots into the new build. Your games, saves, and settings survive because they are on a separate partition from the OS image. The mechanics are documented on the Updates & Downloads page.

Updating from the shell

If you prefer SSH, the same operation is a single command. It respects whichever branch you have configured in updates.type.

# Update to the newest build on your chosen branch, from the shell:
batocera-upgrade
# ...downloads, verifies, and stages the new image; reboot to apply.

When not to update

Resist the urge to update in the middle of a project. If your current build runs every game you care about, a new release can just as easily regress an emulator core as improve one — Batocera tracks upstream libretro and standalone emulators, and upstream is not infallible. Update when you have a reason (new hardware support, a specific fix), not reflexively. And never update right before you plan to actually play something; that is how you discover a regression at the worst possible moment.

Five Pitfalls That Waste Your Afternoon

Every one of these has cost someone an evening on the forums. None of them is exotic. Read the list once and you will recognize the symptom the moment it appears.

Drive and image mistakes

1. Flashing to the wrong drive. The flasher does not know which disk is precious. Confirm the target by size and label in lsblk (Linux) or Disk Management (Windows) before you write. This is the only mistake on the list with no recovery — the erased drive is simply erased.
2. Using an 8 GB stick. It appears to work, then fails the first time you try to update because there is no room to stage the new image. Use 32 GB. The wiki says 16 GB minimum for a reason, and updates are that reason.
3. Double-extracting or mis-extracting the image. People extract the .img.gz, then flash the .gz anyway, or feed an extracted .img to a tool that wanted the archive. Let Raspberry Pi Imager or Etcher consume the .img.gz directly and do not touch the archive at all.

Expectation and process mistakes

4. Expecting games in the box. Batocera ships no ROMs and no BIOS files, full stop. An install that boots to a nearly empty front-end is working correctly; you have simply not added content yet. This surprises people every single day.
5. Powering off during first-boot expansion. The first boot resizes the data partition on a black or logo-only screen for a minute or two. Pulling power because you assumed it hung corrupts the partition table and forces a reflash. Wait for EmulationStation.
6. Trusting content farms and paid 'mirrors.' The near-identical '12 Steps ' posts are machine-spun rewrites of the official wiki, and any site charging for a ROM/BIOS 'members area' is neither official nor legal. Download only from batocera.org; read the real docs at wiki.batocera.org.

Troubleshooting Table

Symptom on the left, cause and fix on the right. This covers the failures that account for the overwhelming majority of first-install support threads.

Symptom	Likely cause	Fix
USB stick never appears in the boot menu	Secure Boot enabled or USB boot disabled	Disable Secure Boot, enable Removable Media Boot, set UEFI mode; try a rear USB port
Boots to a black screen after the logo	Discrete NVIDIA GPU without the proprietary driver	Set nvidia-driver=true in batocera-boot.conf on the FAT partition
System list shows almost nothing	No ROMs added yet, or gamelist not scanned	Copy ROMs to /userdata/roms/<system>, then UPDATE GAMELISTS
Emulator errors about a missing BIOS	Required BIOS absent or wrongly named	Place the exact-named BIOS in /userdata/bios/; verify with the in-menu BIOS check
Controller not detected	Unpaired Bluetooth pad or flaky adapter	Use a wired pad first; pair via CONTROLLER SETTINGS; some BT chips are unreliable
Wi-Fi will not connect	Region unset or unsupported USB dongle	Set country and enable in NETWORK SETTINGS, or pre-seed batocera.conf; use a supported adapter
Update fails partway	Drive too small to stage the new image	Move to a 32 GB drive; the updater needs headroom beyond the running OS
Network share not visible	Hostname not resolving on the LAN	Use \\IP-address\share instead of \\BATOCERA\share; confirm SMB is on
PS2/GameCube runs at single-digit FPS	GPU too weak, or wrong image variant	Use stronger hardware, try the Vulkan renderer, lower internal resolution
Saves seem to vanish after an update	Reflash instead of in-place update, or wrong folder	Saves live in /userdata/saves; in-place updates preserve them, reflashing does not

Advanced Tips & Tuning

Once the box boots and plays games, the interesting configuration begins. Batocera exposes almost everything through batocera.conf and a boot script, which means your entire setup is a couple of text files you can back up, diff, and redeploy.

batocera.conf power-user keys

The master config lives at /userdata/system/batocera.conf. It uses simple key=value lines, and settings can be global or scoped per system and per game. A handful of keys are worth knowing by hand rather than hunting through menus: global.smoothing for bilinear filtering, global.rewind for the rewind buffer, global.autosave for automatic save states, global.retroachievements and the associated username/password keys, and updates.type to pin your branch. You can also pre-seed Wi-Fi credentials here before first boot for a headless install, which beats typing a passphrase with a controller.

## /userdata/system/batocera.conf (excerpt)
system.language=en_US
system.kblayout=us
system.timezone=America/New_York
audio.volume=90

## Pre-seed Wi-Fi for a headless box:
wifi.enabled=1
wifi.ssid=YourNetwork
wifi.key=YourWifiPassword

## Pin the update branch:
updates.type=stable

## Global emulator behaviour:
global.smoothing=1
global.rewind=0
global.autosave=0
global.retroachievements=0

custom.sh boot scripts

For anything the config cannot express, /userdata/system/custom.sh runs at boot with a start argument. Make it executable and you can set a CPU governor, mount a network drive, launch a background service, or tweak a sysfs value. Keep it minimal — every line here is something that can break your boot — but it is the sanctioned place for machine-specific tuning.

#!/bin/bash
## /userdata/system/custom.sh -- runs at boot; must be executable
case "$1" in
  start)
    # Example: pin the CPU governor to performance at boot
    echo performance | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
    ;;
esac

Decorations, shaders, and cores

Batocera's emulator cores are the same libretro cores you would configure by hand in a standalone RetroArch install, which means the tuning knowledge transfers directly — bezels, CRT shaders, run-ahead latency reduction, and per-core options all behave as documented in the libretro documentation. If you came from a manual setup and want to understand what Batocera is doing under the hood, our RetroArch cores guide maps the standalone concepts onto what Batocera bundles. For the source itself — build scripts, supported hardware, issue tracker — the batocera-linux GitHub repository is the ground truth.

A Complete Working Configuration

Here is a full, coherent setup you can adapt: the folder layout, a complete batocera.conf, a custom.sh, and the commands to verify the install actually took. This is the state a working Batocera 43.1 box should be in after you have followed the twelve steps and added content.

The on-disk layout

/userdata/
├── bios/
│   ├── scph5501.bin          # PS1 (US)
│   └── gba_bios.bin          # Game Boy Advance
├── roms/
│   ├── snes/
│   ├── megadrive/
│   ├── psx/
│   └── n64/
├── saves/
└── system/
    ├── batocera.conf
    └── custom.sh

The full batocera.conf

## /userdata/system/batocera.conf -- complete example

## Locale and audio
system.language=en_US
system.kblayout=us
system.timezone=America/New_York
audio.volume=90
audio.device=auto

## Video
global.videomode=default
global.smoothing=1
global.shaders=
global.bezel=default

## Emulation behaviour
global.rewind=0
global.autosave=0
global.retroachievements=0
global.retroachievements.hardcore=0

## Network (headless-friendly)
wifi.enabled=1
wifi.ssid=YourNetwork
wifi.key=YourWifiPassword

## Updates and security
updates.type=stable
system.security.enabled=1

## Per-system override example: run PS1 on the Vulkan-capable core
psx.videomode=default
psx.smoothing=1

Verifying the install

SSH in and confirm three things: the version, that the data partition grew to fill the drive, and that the system sees your ROM folders. Representative output on a 32 GB stick looks like this.

# Confirm the running release:
batocera-version
# 43

# Confirm the data partition expanded to fill the drive:
df -h /userdata
# Filesystem      Size  Used Avail Use% Mounted on
# /dev/sda2        27G  2.1G   24G   9% /userdata

# Confirm your systems are populated:
ls /userdata/roms/
# megadrive  n64  psx  snes

If batocera-version reports 43, df shows a partition filling most of your 32 GB stick rather than a stranded 8 GB, and your ROM folders list the systems you copied, the install is complete and correct. From here it is content and taste — which is the fun part, and the part no download guide can do for you. When you outgrow a single box and start eyeing dedicated handhelds or FPGA hardware, the rest of the site is waiting; the emulation rabbit hole has no bottom, only better-lit sections.