Batocera Download 2026: 43.1 in 12 Steps, 30 Min

There is a specific kind of person who types batocera download into a search box, clicks the first result, grabs whatever file looks biggest, writes it to the nearest SD card, and then spends the evening staring at a black screen wondering why a project with a decade of releases behind it apparently refuses to boot. That person downloaded the wrong architecture. This guide exists so that you are not that person, and so that the thirty minutes the job actually takes stay thirty minutes instead of becoming an evening.

Batocera.linux is a free, open-source, ready-to-run retro-gaming operating system built on Buildroot, fronted by EmulationStation, and powered underneath by RetroArch's libretro cores plus a stack of standalone emulators covering 200-plus systems. The current stable release, as of this writing in 2026, is version 43.1, and the official download page says so in as many words: it lists 'Current version: 43.1.' The homepage tells you the same thing with a large 'Get Batocera.linux 43.1' button. None of that is the hard part. The hard part is understanding what you are actually downloading, because Batocera is not software you install. It is an operating system you photograph onto a disk.

Why Batocera Is an Image, Not an Installer

An operating system you photograph, not install

When you download Batocera you do not get a setup.exe, a .deb, or a wizard asking where to put Start Menu shortcuts. You get a compressed disk image — a file named something like batocera-x86_64-43.1-20260530.img.gz, roughly 3 GB compressed and around 8 GB written out — and the act of 'installing' it is writing that image byte-for-byte onto an entire storage device, overwriting whatever was there. The project's own GitHub description is blunt about this: Batocera is meant to be 'copied to a USB stick or an SD card,' turning any computer or nano-computer into a gaming console. That is the entire deployment model. There is no in-place installer because there is nothing to install into.

The reason for this design is worth understanding, because it explains every quirk in the rest of this tutorial. The Batocera system partition is read-only. The operating system boots from a compressed image and runs largely from RAM; your ROMs, saves, BIOS files, scraped artwork and configuration live on a separate, writable 'userdata' (or 'share') partition. Nothing you do inside EmulationStation ever modifies the OS image. That is why upgrades can be as simple as swapping one partition while leaving your data untouched, and it is why a corrupt download produces bizarre, inconsistent failures rather than a clean error message: you are booting a damaged filesystem, not running a broken installer. The software itself is released under CC-BY-NC-SA, costs nothing, and its full source lives on GitHub.

43 versus 43.1: the Glasswing point release

Batocera 43, codenamed Glasswing, shipped on 8 May 2026. The point release 43.1 followed on 30 May 2026 as a stability patch — it fixed EmulationStation systems and collections disappearing, broken LR-Dolphin options, a Steam and Flatpak issue, and Microsoft controllers being misdetected as keyboards, among other things. It is the version the download page now serves, and it is the one you want. The distinction matters more than point releases usually do in the Linux world. Because Batocera ships device-targeted images rebuilt per architecture, the '43.1' you want is not one file. It is a whole family of images stamped with build dates spanning roughly 29 May to 4 June 2026, one per supported platform. If a mirror is still handing you a base-43 image dated early May, you are downloading three weeks of fixed bugs you do not have to live with. Check the changelog, confirm the '43.1' string, and note the eight-digit date in the filename before you commit.

When you should install RetroPie instead

Batocera is opinionated and turnkey: you flash it, it boots into a games menu, and it hides Linux from you unless you go looking. That is a feature if you want a console and a limitation if you want a workshop. The main alternative on Raspberry Pi hardware is RetroPie, which is a configuration layer you bolt onto Raspberry Pi OS and then tune by hand. If you enjoy that sort of thing — or you have a Pi lying around and do not mind that the RetroPie image has been, as we have documented, frozen at v4.8 with no Raspberry Pi 5 image — RetroPie is the more hackable choice. Batocera, by contrast, ships current Pi 5 builds. If you want to be playing games before the kettle boils, Batocera wins. Choose accordingly; do not flash both to the same card and expect them to negotiate.

Prerequisites: Hardware and Software Versions

Hardware: know your architecture before anything else

Batocera runs on a startlingly wide range of hardware, and the single most consequential decision you make is matching the image to the silicon. The families you will meet in the 43.1 index are: 64-bit PCs (the standard x86_64 build for any Intel or AMD desktop, laptop or mini-PC, plus a separate optimized x86_64-v3 build for newer CPUs); the Raspberry Pi line (bcm2711 for the Pi 4, 400 and CM4, bcm2712 for the Pi 5); Rockchip and other ARM single-board computers (rk3588 and friends); a long tail of handhelds; and, newer to the party, RISC-V boards via the StarFive jh7110 build and Qualcomm Snapdragon 8 Gen 2 handhelds via sm8550. There is even a dedicated build for Allwinner H700 handhelds such as the Anbernic RG40XX V (h700-anbernic-rg40xx-v). If you would rather buy a finished ARM handheld than flash your own, that is a legitimate fork in the road — our Retroid Pocket 6 breakdown covers the Android side of that decision — but everything below assumes you are flashing.

Software: the flashing tools and their versions

You need exactly one tool to write the image, plus a card reader. Any of the following does the job in 2026:

• balenaEtcher (current v2.x line) — cross-platform, writes .img.gz directly without manual extraction, and verifies the write afterward. The safest default for beginners.
• Rufus 4.x (Windows) — faster than Etcher on Windows and better at surfacing the exact target disk, which lowers the odds of nuking the wrong drive.
• Raspberry Pi Imager (1.8 or newer) — the obvious pick for Pi targets. Choose 'Use custom' and point it at the downloaded image.
• dd (Linux and macOS) — no GUI, no guardrails, total control. We use it later for people who prefer a terminal to a progress bar.

Do not use the Windows 'burn disc image' feature, do not rename the file to .iso and send it to a DVD, and do not use the SD Card Formatter tool's restore feature. Those are three separate ways to waste an afternoon and one card.

Storage and RAM: the SD card lie

The 43.1 image itself is small — a couple of gigabytes compressed. That number is a trap, because the OS is the least of your storage concerns. On first boot Batocera expands its userdata partition to fill the device, and userdata is where your ROMs, BIOS files and gigabytes of scraped box art live. On the RAM side the floor is about 1 GB, with 2 GB comfortable. On storage, 8 GB is the technical minimum, but drop below 16 GB and you lose in-place auto-updates entirely — so treat 32 GB as the practical floor and 128 GB or larger (name-brand, rated A2 / V30) as the sane choice, or flash to a USB SSD if your hardware boots from one. The counterfeit-capacity card market is real and thriving, so buy from somewhere reputable and let the flasher's verify pass catch a fake before Batocera does. For a sense of how fast curated libraries balloon, our tour of the Miyoo Mini Plus's 6,041-game aggregations is a sobering reference point.

Step 0: Pick the Right Architecture Image

Decoding the filename schema

Every official Batocera image follows one naming pattern, and once you can read it the download index stops being intimidating:

batocera-[architecture]-[version]-[date].img.gz

# Real 43.1 examples pulled from the download index:
batocera-x86_64-43.1-20260530.img.gz                    # 64-bit PC / laptop / mini-PC
batocera-bcm2711-43.1-20260530.img.gz                   # Raspberry Pi 4 / 400 / CM4
batocera-h700-anbernic-rg40xx-v-43.1-20260604.img.gz    # Anbernic RG40XX V (Allwinner H700)
batocera-jh7110-43.1-20260529.img.gz                    # StarFive JH7110 (RISC-V SBCs)
batocera-sm8550-43.1-20260529.img.gz                    # Snapdragon 8 Gen 2 handhelds

Read it left to right: the project name, the architecture token, the version, and an eight-digit YYYYMMDD build date, all wrapped in a gzipped disk image. The version and date together are your proof that you grabbed 43.1 and not a stale 43. The architecture token is the part that decides whether the thing boots at all.

The architecture cheat-sheet

Here are the tokens you are most likely to meet in the 43.1 index, with the hardware each targets. If you are already running Batocera and want to confirm what board you are on, cat /boot/boot/batocera.board prints it.

Why the wrong image fails silently

This is the failure mode that generates the most forum threads and the fewest useful error messages. If you write the bcm2711 Raspberry Pi image to a PC's USB stick, the PC will not boot it — the bootloader and kernel are compiled for ARM, and your x86 firmware simply shrugs. If you write the x86_64 image to a Pi's SD card, the Pi's firmware looks for its own boot files, does not find them, and sits on a rainbow or black screen forever. In neither case do you get a message that says 'wrong architecture.' You get silence, and silence gets misdiagnosed as a bad card, a dead download, or a broken machine. A 2026 setup guide reasonably estimates the whole install at about thirty minutes, and nearly every failure that blows past that estimate comes down to this one step. Get the token right and the rest is mechanical.

The Download: 12 Steps to a Booting Console

Here is the whole job, start to finish. Follow it in order; each step earns its place, and the rationale after it tells you what you are actually preventing.

1. Open the official download page. Go straight to batocera.org/download. Rationale: it is the canonical index and the only source guaranteed to carry the current 43.1 builds. Third-party mirrors and 'mega-pack' torrents lag, and some carry modified images you do not want anywhere near your hardware.
2. Select your hardware from the picker. The page presents a hardware chooser rather than a raw file list. Pick your exact device. Rationale: it maps your hardware to the correct architecture token so you never have to hand-decode bcm2711 versus sm8550 under pressure.
3. Confirm the version reads 43.1 and note the build date. The filename should contain 43.1 and an eight-digit date in the 20260529 to 20260604 range. Rationale: this is how you prove you are getting the patched point release and not a cached base-43 image with three weeks of unfixed bugs.
4. Download the .img.gz. Save the gzipped image somewhere you can find it. Rationale: the file is meant to stay gzipped. Modern flashers read .gz natively, and manually extracting it just wastes disk and invites mistakes.
5. Verify the checksum. Compare the downloaded file's SHA-256 against the published value (full procedure in the next section). Rationale: a single flipped bit in a multi-gigabyte download produces exactly the kind of intermittent, un-Googleable boot failure that eats entire evenings.
6. Insert the target media and identify it correctly. Plug in the SD card, USB stick or SSD, and note its size. Rationale: the next steps overwrite this device completely. Identifying it by capacity, and unplugging every other external disk, is how you avoid flashing over your backup drive.
7. Open your flasher. Launch balenaEtcher, Rufus, or Raspberry Pi Imager. Rationale: these tools write the image and then read it back to verify, catching a bad card before you have wasted a boot attempt on it.
8. Select the image, select the target, and flash. Point the tool at the .img.gz, choose the correct device, and start. Terminal die-hards can use dd instead (below). Rationale: this is the actual write. Everything before it was preparation and everything after is confirmation.
9. Wait for the verification pass; do not yank the card. Let the flasher finish writing and verifying. Rationale: pulling the media mid-verify leaves a half-written image that boots partway and then falls over in ways that look exactly like a hardware fault.
10. Move the media to the target device and boot it. On a PC, enter firmware/BIOS and put USB or the SSD first in the boot order (disable Secure Boot if it complains); on a Pi or handheld, it just boots. Rationale: a correctly flashed drive that is not first in the boot order looks identical to a drive that did not flash.
11. Let the first boot expand userdata. The first startup resizes the userdata partition to fill the device and builds its directory tree. Give it a minute and do not power-cycle it. Rationale: interrupting this one-time expansion is a reliable way to corrupt the very partition your saves will live on.
12. Configure your controller and set language/region. Hold a button to map the pad, pick your language, and you are sitting in EmulationStation. Rationale: you are done — roughly thirty minutes, most of it download time. Now add ROMs and BIOS files to the userdata share and start playing.

For the terminal crowd, here is step 8 as a one-liner. Identify the disk first — guessing here is how people overwrite the wrong drive:

# Identify the target disk FIRST -- never guess this
lsblk

# Flash it (replace /dev/sdX with YOUR whole device, not a partition like sdX1)
zcat batocera-x86_64-43.1-20260530.img.gz | sudo dd of=/dev/sdX bs=4M status=progress conv=fsync
sync

Verifying Your Download With Checksums

Why a checksum is not optional paranoia

Batocera boots a compressed, read-only filesystem. If a handful of bytes flipped in transit — a flaky connection, a mirror hiccup, a tired USB cable during the copy — the image will often still flash perfectly and then fail at boot in ways that have nothing obvious to do with the download. You will chase phantom hardware faults, reformat good cards, and blame the Pi. A thirty-second checksum comparison up front eliminates the entire category. This is the cheapest insurance in the whole process, and it is the step everyone skips.

Running the hash on every OS

Compute the SHA-256 of the file you downloaded and compare it to the checksum published alongside the image:

# Linux
sha256sum batocera-x86_64-43.1-20260530.img.gz

# macOS
shasum -a 256 batocera-x86_64-43.1-20260530.img.gz

# Windows (PowerShell)
Get-FileHash .\batocera-x86_64-43.1-20260530.img.gz -Algorithm SHA256

Reading the expected output

The command prints a 64-character hexadecimal string next to the filename. It should look like this — the hash below is illustrative, so compare against the value the download page actually publishes, not against this line:

a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2  batocera-x86_64-43.1-20260530.img.gz

If the two strings match character for character, flash with confidence. If they differ by even one digit, delete the file and download it again, ideally from the official page rather than whatever mirror handed you the corrupt copy. Do not 'just try flashing it anyway.' That is how a five-minute re-download becomes a two-hour debugging session.

Upgrading In-Place: batocera-upgrade

check-updates, then upgrade

Once Batocera is running, you rarely need to reflash to move to a newer release. The system carries its own updater. From a terminal — on the device itself or over SSH — the two commands you care about are documented in the official wiki:

# Check whether a newer build exists for your architecture
batocera-check-updates

# Download and stage the latest stable build, applied on next reboot
batocera-upgrade

batocera-check-updates compares your installed build against what is available online and reports whether an update exists; batocera-upgrade then downloads the new boot image for your architecture and stages it so the next reboot lands on the new version. A typical check looks like this:

Local version:  43
Online version: 43.1
A newer version is available.

Your userdata partition — ROMs, saves, configs — is untouched, because, as established, the OS and your data live on different partitions by design. Note that in-place auto-updates require more than 8 GB of storage, which is one more reason the 32 GB practical floor from earlier matters.

Targeting a specific build folder or mirror

The upgrader is not limited to 'whatever the default channel serves.' The wiki documents passing an explicit build-folder URL, which lets you pull a specific version from a specific mirror rather than trusting the top-level landing page:

# Point the upgrader at an explicit build folder on a chosen mirror
batocera-upgrade https://mirrors.o2switch.fr/batocera/x86_64/stable/last/

This is how you pin an upgrade to a known-good mirror, or fetch a particular architecture's stable 'last' folder directly. It matters because Batocera's release infrastructure is mirrored and architecture-aware; the download page is a convenience layer over a directory tree you can address yourself when you need to. Swap last for a version number like 36 and you can pull an older folder for a deliberate downgrade.

SSH is the modern, supported path

For every version since 5.23, the project explicitly recommends performing upgrades and downgrades with batocera-upgrade over SSH rather than shuffling files by hand. Batocera enables SSH out of the box; the default login is root with the password linux, which you should change immediately:

# Connect over the network (Batocera enables SSH by default)
ssh root@BATOCERA_IP_ADDRESS
# default password: linux  -- change it in the EmulationStation settings after login

Running the upgrade over SSH gives you a real terminal, readable progress, and an error log if something goes wrong — none of which you get from a frozen on-screen progress bar. Treat the manual method in the next section as the fallback for when the network path genuinely is not available.

Manual Upgrade and Downgrade: boot.tar.xz

When the manual method is unavoidable

Sometimes batocera-upgrade is not an option: the device has no working network, you are moving between versions the updater will not bridge, or you specifically need to downgrade because a new release broke your particular hardware. For those cases the project distributes the boot filesystem as a compressed boot.tar.xz archive. There are, in practice, three tiers of manual, from least to most hands-on.

The three-tier boot.tar.xz procedure

The modern semi-manual method (v39 and up) is the gentlest: download the correct boot.tar.xz for your target version, drop it into /userdata/system/upgrade/ on the running system, and run batocera-upgrade — it detects the staged archive and applies it on the next reboot, no partition surgery required. The fully manual method is the brief's classic: pull the drive, decompress the archive to a plain boot.tar, and extract it over the drive's boot partition by hand.

# 1) Decompress the archive to a plain tar (Windows: 7-Zip does this too)
unxz boot.tar.xz            # produces boot.tar

# 2) Back up your customized boot settings BEFORE touching anything
cp /boot/batocera-boot.conf /boot/batocera-boot.conf.bak
cp /boot/config.txt         /boot/config.txt.bak

# 3) Extract boot.tar over the Batocera boot partition
tar -xf boot.tar -C /media/BATOCERA_BOOT/

Either way you are replacing the contents of the boot partition — kernel, the system image, the bootloader bits — with the target version's. The userdata partition is deliberately left alone, so your library survives the swap, and on the next power-up the device boots the version you laid down.

Back up batocera-boot.conf and config.txt first

Here is the part people skip and then regret. If you have customized your boot settings — a non-default userdata location, overclock or display tweaks in config.txt on a Pi, a specific sharedevice in batocera-boot.conf — extracting a fresh boot.tar overwrites those files with stock defaults. The wiki warns about this explicitly. Copy both files somewhere safe before you extract, then reapply your changes afterward. Two cp commands now save you a 'why did my external drive stop mounting' mystery later. This is precisely why the SSH path is preferred for anything 5.23 and newer: it handles the boot-config preservation for you.

The Batocera Store, ROMs, and the Law

store.batocera.org and the Content Downloader

Batocera ships an official content system — the 'store,' reachable at store.batocera.org and surfaced inside the system as a downloader. Per the wiki, it can pull freely distributable ROMs, bezel and overlay packs, music themes, and other enhancements straight onto the device. Under the hood it leans on the pacman package manager (yes, the one from Arch) to install, upgrade and remove that content cleanly, which is a good deal more civilized than dragging zip files around by hand.

What is actually free, and what is not

Read 'freely distributed' precisely, because it is doing real work in that sentence. The store offers homebrew, public-domain titles, and games whose rights-holders have explicitly allowed redistribution. It does not offer — and Batocera does not ship — commercial ROMs or the BIOS files that certain systems require. Those you are expected to provide yourself, and the law here is less forgiving than forum folklore suggests. In the United States there is no blanket statutory right to download a 'backup' of a game you own on cartridge; the closest defensible position is dumping your own physical media, and even then distributing the result to anyone else is straightforwardly infringing. If you want to stay on the right side of it, dump the carts you actually own — our Retrode walkthrough covers exactly that, SNES and Genesis, in about half an hour. And if you would rather curate a smaller, hand-picked set than a sprawling dump, the discipline behind the Miyoo Mini Plus's community game lists is a useful model.

pacman under the hood, and the libretro cores it feeds

The store's real job is delivering content to an emulation stack you did not have to assemble. Batocera's emulator layer is built on RetroArch and its libretro cores — the same cores documented at docs.libretro.com — plus standalone emulators for systems that run better outside RetroArch. When you install a bezel pack or a shader set from the store, pacman is placing files where those cores expect them. You can ignore the store entirely and populate the userdata share manually; the store simply automates the tedious, well-understood parts. If your interest runs more toward cycle-accurate FPGA hardware than software cores, that is a different rabbit hole — see our look at the MiSTer Multisystem 2 — but for a flash-and-play software console, the libretro stack Batocera bundles is the pragmatic default.

6 Common Pitfalls (And Their Fixes)

Nearly every Batocera download that goes wrong goes wrong in one of six specific ways. Here they are, with the fix for each.

Flashing mistakes

1. Manually extracting the .img.gz, or double-extracting it. People decompress the gzip to a raw .img and then feed the .gz to the flasher anyway, or extract twice and end up with garbage. Fix: leave the file gzipped and hand the .img.gz straight to Etcher, Rufus or Pi Imager. They read gzip natively. dd users pipe through zcat, as shown earlier.
2. Flashing the wrong disk. The classic: you select your external backup drive instead of the SD card and wipe it. Fix: identify the target by exact capacity, unplug every other external disk before flashing, and use a tool (Rufus, lsblk) that shows the device size explicitly.

Boot failures

3. Wrong architecture image. The bcm2711-on-a-PC or x86_64-on-a-Pi black screen, which produces no error at all. Fix: re-download using the hardware picker on the official page and confirm the architecture token matches your device before flashing.
4. Secure Boot or boot order blocking a PC install. The card flashed fine but the PC boots straight to Windows or an 'no operating system' message. Fix: enter firmware setup, disable Secure Boot, ensure USB/removable boot is enabled, and move the Batocera drive to the top of the boot order.

Storage and first-boot failures

5. A counterfeit or worn-out SD card. Fake-capacity cards pass a quick glance and then fail the flasher's verify pass or corrupt userdata within a week. Fix: buy name-brand A2/V30 media from a reputable seller, and never ignore a verification failure — it is the card telling you the truth.
6. Interrupting the first-boot userdata expansion. Power-cycling during that initial resize corrupts the partition your saves will live on. Fix: on the very first boot, leave it alone until EmulationStation appears. If you already interrupted it, reflash and start over rather than fighting a half-built partition.

Troubleshooting Table: 10 Failures

How to use this table

Match the symptom to the row, apply the one fix, and resist the urge to try three fixes at once — that is how you turn one problem into a diagnosis you cannot reverse. Most of these trace back to the download or the flash, not the hardware.

The failures and their fixes

When none of these apply

If you have worked the table and you are still stuck, the two highest-value moves are: re-verify the checksum (you would be amazed how often 'impossible' boot behavior is just a corrupt image), and cross-check the architecture token one more time against the official hardware picker. Between those two you have eliminated the causes behind the large majority of failed Batocera downloads.

Advanced: Mirrors, Betas, and Netboot

Addressing mirrors and build folders directly

The download page is a friendly front end over a directory tree, and once you know the shape of that tree you can bypass the front end entirely. Community mirrors expose per-architecture stable/last/ folders — for example the o2switch mirror at https://mirrors.o2switch.fr/batocera/x86_64/stable/last/ — that always point at the newest x86_64 stable build. You can download from there directly, or hand that URL to batocera-upgrade, as covered earlier. This is genuinely useful when the main page is slow, geoblocked, or serving a stale cache, and it is the officially documented way to pin a specific build.

Beta builds, nightlies, and deliberate downgrades

Beyond the stable channel, Batocera publishes beta and development builds, tracked on the wiki's current and previous releases page. Betas are where new hardware support and emulator bumps land first; they are also where new bugs land first, so treat them as test rigs, not daily drivers. The same infrastructure that serves betas serves older stable builds, which is how you perform a deliberate downgrade when a release regresses on your specific device — grab the previous version's boot archive and apply it via the manual boot.tar.xz method above. If you have ever tracked a hardware product through a dozen firmware revisions — the kind of discipline we walked through with the Analogue 3D's build history — the instinct to keep a known-good previous image on hand will feel familiar. It is cheap insurance.

Running from USB, netboot, and multi-machine setups

Because Batocera is just an image with a read-only system and a separate userdata partition, it lends itself to arrangements a normal install cannot manage. You can run the whole OS from a USB stick or external SSD and leave the internal drive untouched — ideal for turning a shared family PC into a console at reboot without committing to it. For multi-machine households, Batocera supports network-mounted userdata and even netboot, so several thin clients can share one library over the LAN. These are niche, but they fall out naturally from the image-based model, and they are the payoff for a design that at first looks inconvenient. The full, authoritative documentation for all of it lives on the Batocera wiki.

The Complete Working Configuration

Where your files live: the userdata layout

Once you are booted, everything you add lives under /userdata, and knowing its shape saves you a lot of guesswork. ROMs go in per-system folders named by their short name; each system folder carries an _info.txt listing the exact formats that system's cores accept. BIOS files go in a single flat folder. The tree looks like this:

/userdata/
  roms/        # game files, one folder per system shortname (roms/snes, roms/genesis, ...)
               # each roms/[system] holds an _info.txt of accepted formats
  bios/        # BIOS / firmware files the cores expect
  saves/       # in-game saves and save states
  system/      # configuration, including batocera.conf

Over the network the userdata folder is shared automatically — from Linux or macOS you reach it at smb://BATOCERA.local/share, and from Windows you browse to the BATOCERA host in File Explorer. Drop ROMs and BIOS files in over the network, then refresh the game lists from START, Game Settings, Update Gamelists.

A known-good batocera-boot.conf

Two config files matter and they are easy to confuse. /userdata/system/batocera.conf holds your emulator and system settings; /boot/batocera-boot.conf is the low-level file that governs where Batocera looks for its userdata. For the overwhelming majority of installs the boot defaults are correct and you never touch them — but if you are doing anything clever (running the OS from a USB stick while keeping your library on the internal disk, say), this is the file you edit. Here is an annotated, working baseline:

# /boot/batocera-boot.conf -- tells Batocera where to find its userdata
# --------------------------------------------------------------------

# Volume label of the boot partition (leave as BATOCERA)
label=BATOCERA

# Where the writable userdata ('share') partition lives:
#   INTERNAL    = same drive you booted from    (default, recommended)
#   ANYEXTERNAL = first external disk found      (OS on USB, games elsewhere)
#   RAM         = ephemeral, wiped on reboot      (kiosk / testing only)
#   DEV <uuid>  = a specific partition by UUID
sharedevice=INTERNAL

# Seconds to wait for the share device to appear before falling back
sharewait=6

The sharedevice=INTERNAL line is the one that matters most: it tells Batocera to keep userdata on the same drive you booted from, which is what you want for a standard single-drive install. Change it to ANYEXTERNAL to run the OS from one device and store games on another, or to a specific DEV UUID to pin userdata to an exact partition. Back this file up before any manual upgrade, as covered above.

The end-to-end recap

Compressed to its essentials, the entire download-to-playing path is:

1. Confirm the current release is 43.1 on batocera.org/download and cross-check the changelog.
2. Use the hardware picker to get the right architecture image (verify the token and the 43.1/date in the filename).
3. Verify the SHA-256 checksum.
4. Flash the .img.gz to A2/V30 32 GB-plus media with Etcher, Rufus, Pi Imager, or dd.
5. Boot, let userdata expand, map a controller — about thirty minutes, mostly download time.
6. Thereafter, update in place with batocera-check-updates and batocera-upgrade over SSH; keep a previous boot archive for downgrades.

With a booting 43.1 install, the remaining work is content and taste: populate the userdata share with BIOS files and ROMs you are entitled to, scrape artwork, and tune per-system options. The project's source, issue tracker and build recipes are on GitHub, the core-by-core reference is at docs.libretro.com, and everything device-specific is on the wiki. Batocera's download step is genuinely a five-minute affair once you stop treating it like an app store and start treating it like what it is: an operating system you write to a disk, whole, and boot. Pick the right architecture, verify the bytes, and the black-screen evening never happens.