Batocera Download 2026: 43.1 in 12 Steps, 30 Minutes

There is no Batocera installer. There is no setup wizard that walks you through partition sizes and driver selection while a progress bar pretends to be your friend. Batocera.linux is an image - a frozen, read-only snapshot of an entire operating system - and downloading Batocera means fetching that image, writing it byte-for-byte onto a card or a stick, and booting the result. That is the whole job. Everything that goes wrong goes wrong in one of those three moves, and it goes wrong for boring, reproducible reasons that this article exists to eliminate.

As of August 22, 2026 - the day the official download page was last touched - the current stable release is Batocera 43.1, codenamed Glasswing. The 43 series landed on May 8, 2026; the 43.1 point release followed on May 30, 2026. If a guide, a forum post, or a helpful stranger tells you to grab the latest Batocera without naming a number, assume the information is stale and verify against the source before you burn twenty minutes flashing a card. This tutorial pins every claim to a version and a date, because in retro-gaming the difference between works and black screen is frequently a single build number.

A note on the clock in the headline: the thirty minutes is hands-on time - verify, flash, first boot, basic configuration. The download itself is a function of your connection and the mirror, and it is the one part of this process you do not control. Everything else is under your command, and this guide is about not squandering it.

What Batocera 43.1 Actually Is

Before you download anything, understand what you are downloading, because the architecture of the thing explains almost every quirk of the process. Batocera is not a desktop Linux you install games onto. It is a console firmware that happens to run on commodity hardware, and that distinction is the whole story.

An appliance, not a desktop

Batocera is a read-only, immutable Linux appliance built to do exactly one thing: boot straight into EmulationStation and run emulators. You do not apt-get anything. There is no traditional package manager waiting for you; there is a curated set of emulator cores, a frontend, and a writable user-data partition where your ROMs, saves, and configuration live. The system partition is read-only by design, so that a bad shutdown - the default way anyone turns off a game console, which is to say yanking the power - cannot corrupt it. This is the same architectural decision that makes Batocera feel like console firmware rather than a PC operating system, and it is precisely why installing software on Batocera mostly means downloading a different image.

Batocera is built on the same libretro and RetroArch foundation as most of the retro-gaming world, which means if you already understand cores, you already understand most of Batocera. If you do not, our walkthrough on installing RetroArch cores in 12 steps covers the mental model that Batocera inherits wholesale. The frontend you see on boot is EmulationStation; the machinery underneath it is largely the same libretro stack you would configure by hand on a bare RetroArch install, minus the configuring by hand.

Free, open-source, and legally honest

Per Batocera's own homepage, Batocera.linux is an open-source and completely free retro-gaming distribution that you copy onto a USB stick or an SD card to turn a computer or a nano-computer into a gaming console. Completely free is the operative phrase and it is worth reading literally: there is no paid tier, no license key, no pro edition, no unlock. Anyone selling you a Batocera SD card preloaded with thirty thousand games for a marked-up price is selling you two things - a commodity flash card and a copyright problem. The distribution is free; the ROMs those sellers include are, in almost every jurisdiction, unambiguous infringement. Batocera ships zero games. It ships the machine that runs games you supply.

If you want ROMs you can defend in a single sentence, dump your own cartridges. Our Retrode cartridge-dumping walkthrough covers the only supply chain that survives contact with a lawyer: a physical cart you own, a reader, and a file that never left your house. Everything else is a risk calculation dressed up as a hobby, and that is your calculation to make, not ours to make for you.

Glasswing, 43.1, and the numbers that matter

The version situation in mid-2026 is refreshingly unambiguous, so let us fix it in place and move on. Batocera 43 Glasswing is the current major series. 43.1 is the current stable point release. The official changelog dates 43.1 to 2026/05/30. The project's own timeline describes the 43 cycle with approximate dates spanning 2025 to 2026, which is a polite way of saying the release cadence is when it is ready. For a download tutorial, only two facts matter here: first, 43.1 is the build you want, and second, build dates are baked into the filename, so you can tell at a glance whether a mirror is serving you the real thing or a nine-month-old cache someone forgot to purge.

Prerequisites: Hardware and Versions

The prerequisites for a Batocera download are unusually concrete, which is a gift: get these four things right - architecture, storage, flashing tool, and verification tool - and the rest of the process is mechanical. Get any of them wrong and you will spend an evening blaming software for a hardware problem.

The four architectures that matter

Batocera builds a separate image per hardware family, and downloading the wrong one is the single most common failure in this entire process. The image is not universal. An x86_64 image will not boot a Raspberry Pi; a Pi image will not boot your PC. There is no fallback, no compatibility layer, no boot-anyway mode. The four families most readers will care about, using Batocera's own build identifiers and the real 43.1 filenames:

Architecture ID	Target hardware	Example 43.1 filename
x86_64	Any 64-bit PC, laptop, mini-PC, most Intel/AMD handhelds	batocera-x86_64-43.1-20260530.img.gz
bcm2712	Raspberry Pi 5	batocera-bcm2712-43.1-20260529.img.gz
bcm2711	Raspberry Pi 4 / Pi 400	batocera-bcm2711-43.1-20260530.img.gz
sm8250	Snapdragon 865 handhelds (mobile/handheld chipset)	batocera-sm8250-43.1-20260530.img.gz

Note that the build dates differ by a day across architectures - the x86_64 and bcm2712 torrents carry 20260529 while the bcm2711 and sm8250 builds carry 20260530. This is normal; the build farm does not stamp every target at the same second, and a one-day spread across a release is expected rather than alarming. It is also a useful tell: a legitimate 43.1 image carries a late-May-2026 date. If a file claims to be 43.1 but is dated last autumn, you are looking at a mislabelled cache, and you should walk away from that mirror.

Hardware ambition maps to silicon. For 8-bit and 16-bit systems - NES, SNES, Genesis, Game Boy - essentially any of these targets is overkill. For PlayStation, Dreamcast, N64, and PSP you want the muscle of an x86_64 box or, at minimum, a Pi 5. The Pi 4 is a competent 8/16/32-bit machine and a frustrated one above that ceiling. If your target is an Android-class handheld rather than dedicated hardware, note that some devices run Batocera and some are happier under other distributions entirely - our Retroid Pocket 6 versus 5 breakdown covers the SoC realities that decide which chipset image, if any, actually applies to a given handheld.

Storage: the part everyone gets wrong

This is where people lose an afternoon, so read it twice. The requirements, in order of how often they are ignored:

• Capacity. 8 GB is the technical floor; nobody sane should use it. 32 GB is a reasonable minimum, and 128 to 256 GB is where most real builds live once ROMs arrive. Batocera itself occupies roughly 2 GB; everything above that is your library.
• Card class. Buy an A1 or A2 application-class card, UHS-I at minimum. The A-rating measures random I/O - the thing that actually determines whether your menu stutters - not the giant sequential number printed on the package. A cheap 80 MB/s card with no A-rating will feel slower inside EmulationStation than a properly rated 32 GB card, because scanning thousands of ROMs is a random-read workload, not a sequential one.
• Counterfeits. Fake-capacity cards remain endemic. A card that claims 512 GB for nine dollars is a 32 GB card with lying firmware, and it will corrupt silently the moment you exceed its real size. Buy from a seller with a return policy and verify with a tool before you trust it with a library.
• USB versus SD. On x86 you can flash the image to a USB stick and run from it exactly as you would an SD card. That is the recommended way to test Batocera before committing a drive. Use a USB 3.0 port and a USB 3.0 stick; a USB 2.0 stick will boot and then punish you for the choice every time the menu redraws.

The software you install first

You need exactly one flashing tool and, optionally, one verification tool. The safe, boring choices:

• balenaEtcher (current 1.x series) - cross-platform, understands .img.gz directly with no manual decompression, and refuses to write to your system disk by default. This is the recommendation for anyone who does not want to think about it.
• Raspberry Pi Imager (current 1.x) - for Pi targets; it can flash a custom .img.gz, but see the pitfalls section, because its OS-customization prompt does not understand Batocera and will offer to configure things that do not apply.
• dd - already present on every Linux and macOS system. The honest tool. It does exactly what you tell it, including destroying the wrong disk if you tell it to.
• Verification (optional but recommended): sha256sum on Linux/macOS or certutil on Windows to check the download, plus f3 (Linux/macOS) or H2testw (Windows) to check the card is genuine before you trust it.

Which Image Do You Download?

You have identified your architecture. Now you have to fetch the correct file, and the good news is that Batocera's naming scheme is a barcode: once you can read it, you never download the wrong thing again.

Reading the filename like a barcode

Every Batocera image follows one naming pattern. A 2026 third-party setup guide documents it as batocera-[architecture]-[version]-[date].img.gz, and once you internalize the four fields you can audit any download link before you click it:

batocera-[architecture]-[version]-[date].img.gz
         |             |         |
         |             |         +--- .gz : gzip-compressed disk image
         |             +------------- build date, YYYYMMDD
         |             
         +--------------------------- release, e.g. 43.1

 hardware family, e.g. x86_64 / bcm2712 / bcm2711 / sm8250

Worked example: batocera-x86_64-43.1-20260530.img.gz decodes to the x86_64 build of release 43.1, compiled on 30 May 2026, delivered as a gzip-compressed image. If any of those four fields looks wrong - an architecture you do not own, a version below 43.1, a date from last year - stop and re-fetch. The filename is the label. Read the label before you flash it, not after.

Direct download versus torrent

The official download page offers two delivery methods, and they produce byte-identical images. Neither is more official than the other; they are two roads to the same file.

• Direct download. An HTTPS link from a mirror. Simple, works everywhere, and as fast as the mirror and your line allow. This is the right choice for the majority of people on the majority of days.
• Torrent. The official torrent index publishes per-architecture .torrent files - for example batocera-x86_64-43.1-20260529.img.gz.torrent, batocera-bcm2712-43.1-20260529.img.gz.torrent, batocera-bcm2711-43.1-20260530.img.gz.torrent, and batocera-sm8250-43.1-20260530.img.gz.torrent. Torrents are faster on release day when mirrors are hammered, more resilient on flaky connections because they resume and self-verify chunks, and they reduce load on the project's infrastructure. The only cost is a torrent client.

There is a subtle integrity benefit to the torrent worth stating plainly: BitTorrent verifies every piece against the torrent's hash as it downloads. A completed torrent is, by construction, not corrupt. A direct HTTP download carries no such guarantee, which is exactly why the verification step below exists for direct downloads and does not for torrents.

The decision table

If you want the choice made for you, match your situation to a row and stop deliberating:

Your situation	Grab this
Fast connection, just want it done	Direct download for your architecture (x86_64 / bcm2712 / bcm2711)
Release day, or a slow or flaky line	Torrent for your architecture (resumes, self-verifies)
You distrust an ISP transparent proxy	Torrent - per-chunk hashing catches tampering
Air-gapped final machine	Download and verify on another box, then sneakernet the image

Download and Verify in 12 Steps

Here is the full sequence, each step with the reason it exists. Skipping a step is allowed only once you understand what it was protecting you from. The first five are about getting the right file; the middle four are about proving it is intact and your card is real; the last three are about writing it without regret.

1. Confirm your architecture. Identify the exact hardware you will boot: a PC, mini-PC, or x86 handheld (x86_64); a Raspberry Pi 5 (bcm2712); a Pi 4 (bcm2711); or a Snapdragon 865 device (sm8250). Rationale: the image is hardware-specific, and this single decision prevents the most common failure in the whole process. Write the identifier down where you can see it.
2. Go to the official source. Open the official download page at batocera.org/download. Rationale: third-party mirrors and preloaded resellers are how you end up with tampered images or a stale build. The official page is the only canonical index, and it was last updated 2026-08-22.
3. Verify the version reads 43.1. The page should advertise 43.1; the homepage says the same thing with its Get Batocera.linux 43.1 banner. Rationale: if the page shows something older, you are looking at a cache or an unsynced mirror. Refresh, or switch mirrors, before proceeding.
4. Choose direct or torrent. For most people, direct download. On release day or a poor connection, open the torrent index and grab the .torrent for your architecture. Rationale: both yield identical images; the choice is purely speed and resilience, not correctness.
5. Start the download. Save the .img.gz somewhere you will find it again, and confirm the filename matches batocera-[arch]-43.1-[date].img.gz with a late-May-2026 date. Rationale: the filename is your first integrity check - wrong architecture or wrong date means wrong file, and you catch it here for free.
6. Wait for a complete transfer. The compressed image is on the order of a couple of gigabytes. Do not interrupt it, do not sleep the machine mid-transfer. Rationale: a truncated .gz either fails to decompress or, worse, flashes a partial image that boots halfway and then dies with no useful error.
7. Verify the download hash (direct downloads). Run sha256sum against the file and compare it with the checksum the project publishes. Rationale: plain HTTP has no built-in integrity check, and a single flipped bit from a bad mirror produces a card that boots erratically and wastes an evening. Torrent downloads are already verified per chunk and can skip this.

$ sha256sum batocera-x86_64-43.1-20260530.img.gz
3f2a9b0c...(64 hex chars total)...e17d  batocera-x86_64-43.1-20260530.img.gz
# if this matches the checksum on the download page, flash it.
# if it does not, re-download - ideally from a different mirror.

8. Verify the card is genuine (recommended). Before trusting a new or unknown SD card, run f3 (f3probe/f3write/f3read on Linux/macOS) or H2testw on Windows. Rationale: counterfeit-capacity cards pass a casual glance and then corrupt everything written past their real size. Five minutes here saves a full rebuild later.
9. Identify the target device node. Insert the card or stick and find its device name - /dev/sdX or /dev/mmcblkX on Linux, /dev/diskN on macOS, or the drive letter on Windows. Use lsblk to be certain. Rationale: flashing writes raw bytes to whatever you name, and naming the wrong disk destroys it silently. This is the step to slow down on.

$ lsblk -dpo NAME,SIZE,MODEL
NAME            SIZE MODEL
/dev/sda      931.5G Samsung SSD 870       # <== system disk. DO NOT TOUCH.
/dev/sdb       28.9G Generic MassStorage   # <== the 32 GB card you inserted.

10. Decompress if your tool needs it. balenaEtcher and Raspberry Pi Imager read .img.gz directly, so skip this. For dd you either decompress first with gunzip or stream it in one pipe (shown in the flashing section). Rationale: dd writes literal bytes; hand it a .gz and it flashes the compressed file, which boots absolutely nothing.

# only if you plan to keep an uncompressed .img around:
$ gunzip -k batocera-x86_64-43.1-20260530.img.gz
$ ls -lh batocera-x86_64-43.1-20260530.img
-rw-r--r-- 1 user user 7.9G May 30  2026 batocera-x86_64-43.1-20260530.img
# -k keeps the original .gz; the decompressed image is several GB.

11. Flash the image. Use your chosen tool - the next section covers all three - and let it finish and validate. Rationale: an unverified flash is a coin toss. Every serious tool re-reads the card after writing to confirm the bytes landed; let it do that.
12. Eject cleanly and boot. Unmount or eject before pulling the card - writes are buffered, and yanking early truncates them. Move the card to the target, boot it, and select it as the boot device if the firmware needs telling. Rationale: the first boot triggers a one-time partition resize, and a clean eject is what makes that first boot healthy instead of half-written.

Flashing the Image to Media

Three tools, three temperaments. Pick by how much you want to understand versus how much you want to be protected from yourself. All three write the same bytes; they differ only in how loudly they warn you before doing it.

balenaEtcher: the no-thinking path

Three clicks and a verification pass. Point Etcher at the .img.gz (it decompresses on the fly), point it at the card, and let it write and validate. Etcher's single genuinely valuable feature is that it hides your system disks by default, which is the one mistake you cannot undo. If you have never done this before, use Etcher and skip the rest of this section without guilt.

Expected output is a Flash Complete banner with a validation checkmark. If validation fails, the card is the suspect, not the image - counterfeit or dying flash is the usual culprit. Try a different card before you re-download anything, because re-downloading a good image to fix a bad card is a category error.

dd: the honest path

For those who want to know what Etcher is doing on their behalf. dd copies bytes from an input file to an output device with no ceremony and no safety net. The canonical Batocera one-liner streams the gzip straight to the card, decompressing in flight so you never keep a huge .img on disk:

# Linux: replace /dev/sdX with the WHOLE-DISK node from step 9 (sdb, NOT sdb1).
$ gunzip -c batocera-x86_64-43.1-20260530.img.gz | \
    sudo dd of=/dev/sdX bs=4M status=progress conv=fsync

# macOS: the raw node /dev/rdiskN is faster; use gzcat instead of gunzip -c.
$ gzcat batocera-x86_64-43.1-20260530.img.gz | \
    sudo dd of=/dev/rdiskN bs=4m
$ sync

A few notes. bs=4M is a throughput choice, not magic - it batches the writes into sensible chunks. conv=fsync forces the buffer to flush before dd reports done, so finished actually means finished and not still-writing-in-the-background. macOS dd shows no progress bar by default; press Ctrl-T for a one-line status. And the target of= must be the whole disk (/dev/sdb), never a partition (/dev/sdb1), because you are writing a partition table and therefore need the disk itself, not a slice of it.

The warning bears repeating in full: dd overwrites whatever you name, instantly, with no confirmation prompt. It is affectionately expanded as disk destroyer for exactly this reason. Re-read your lsblk output. Then read it again. The disk you flash is the last thing that happens to its former contents.

Raspberry Pi Imager: for Pi, with a caveat

For Pi targets, Imager is convenient: choose Use custom, select the .img.gz, pick the card, write. The caveat - and it catches people every single release - is the OS-customization dialog. Imager offers to preset a hostname, Wi-Fi, SSH keys, and locale. Those settings are written for Raspberry Pi OS's first-boot system, which Batocera does not use at all. At best they are silently ignored; at worst the prompt convinces you that Batocera is misconfigured when in truth it simply never read them. Decline customization, flash the raw image, and configure Wi-Fi from EmulationStation or batocera-boot.conf instead, as covered in the advanced-tips section below.

First Boot and ROM Placement

The flash is done. The next few minutes are the only genuinely automatic part of the whole process, and the most important thing you can do during them is nothing. Let the machine work.

The one-time partition resize

A freshly flashed card carries two partitions: a small FAT32 boot partition and a user-data partition sized to the image, not to the card. On first boot Batocera automatically expands the user-data partition to fill all remaining space. This happens exactly once and takes anywhere from a few seconds to a couple of minutes depending on card size and speed. Do not interrupt it. If you flashed a 256 GB card and the first boot pauses briefly on a text console before EmulationStation appears, that pause is the resize earning its keep.

You can confirm the resize succeeded once you have a shell. SSH is enabled by default - user root, password linux, which you should change immediately on any networked machine:

$ ssh root@batocera            # or root@<ip-address> ; default password: linux
batocera:~# df -h /userdata
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb2       229G  2.1G  227G   1% /userdata
# 229G on a 256GB card = the resize worked. still showing ~5G = it did not.

Where ROMs and BIOS actually go

Everything you own lives under /userdata. The layout that matters:

• /userdata/roms/<system>/ - one folder per system (snes, megadrive, nes, psx, n64, dreamcast, and so on). Drop each ROM into the folder that matches its console.
• /userdata/bios/ - BIOS and firmware files, kept flat and named exactly as the emulators expect. Batocera's built-in BIOS checker lists every required filename and its MD5, so you are never guessing.
• /userdata/saves/, /userdata/screenshots/, /userdata/system/ - saves, captures, and configuration respectively. The last one holds batocera.conf, the file that makes your build yours.

Batocera reads this tree on boot and after a UI refresh. Add ROMs, then update the game list (Menu > Game Settings, or simply restart EmulationStation) and they appear. Do not put ROMs on the boot partition - it is read-only firmware, not storage, and it will ignore them.

The network share: the sane way to load ROMs

The civilized way to move ROMs is over the network, not by shuffling the card between machines like it is 2004. Batocera advertises an SMB share on the LAN under the hostname BATOCERA. From another computer:

• Windows: open \\BATOCERA\share in Explorer.
• macOS: Finder > Go > Connect to Server > smb://BATOCERA/share (or smb://<ip>/share if name resolution is being difficult).
• Linux: smb://BATOCERA/share in your file manager, or mount it with mount.cifs.

The share maps directly onto /userdata, so \\BATOCERA\share\roms\snes is the exact same folder as /userdata/roms/snes. Copy ROMs in over Ethernet or Wi-Fi, refresh the list, done. It is also the fastest way to drop in BIOS files and shaders without ever touching the hardware again.

If your ambition is a handheld rather than a living-room box, the calculus shifts - small screens, small batteries, and locked firmware change what is worth running. Our Miyoo Mini Plus library breakdown is a reality check on where the PS1 wall sits on constrained silicon, and it is the same wall Batocera hits on a Pi 4: fine up to the fifth generation, increasingly optimistic beyond it.

Updating After Install

You downloaded once. You should almost never download-and-reflash again, because Batocera updates itself in place and keeps your library intact while doing it. Understanding the update path is what separates a machine you maintain from a machine you keep rebuilding from scratch.

The EmulationStation route

Per Batocera's official Updates and Downloads wiki, the normal update path lives inside EmulationStation itself: press START to open the main menu and navigate to Updates & Downloads. From there Batocera checks its update channel, tells you whether a newer build exists, and can download and apply it in place. Within a major series - staying on 43.x - this is a one-click affair, and it preserves /userdata entirely. Your ROMs, saves, and configuration survive because they live on a separate partition the update never touches. The same Updates & Downloads area hosts the Content Downloader for themes, bezels, and other extras.

Set your channel deliberately. Batocera offers a stable channel and a beta channel; batocera.conf exposes this as updates.type=stable or beta. Unless you actively enjoy debugging someone else's work-in-progress, stay on stable. Beta is where 44 is being assembled; it is not where your Friday-night library should live.

batocera-upgrade from a shell

There is a command-line equivalent for people who live in a terminal or need to script the thing. With no arguments, batocera-upgrade updates within your current series. To move to a specific build, the project's timeline documentation notes that you pass the URL of a build folder - batocera-upgrade [url of the build folder] - and the wiki lists a mirror example for stable builds:

# update within the current 43.x series (interactive):
batocera:~# batocera-upgrade

# jump to a specific build by pointing at a mirror's build folder:
batocera:~# batocera-upgrade https://MIRROR/batocera/x86_64/stable/last-v43/

# mirrors rotate: pull the current URL from the official wiki, not
# from a year-old forum post that a search engine surfaced first.

The rationale for the URL form is precision: it lets you pin to an exact series or roll forward across a major version without the GUI, and it is the documented way to target a build the in-app updater will not otherwise offer you. It is the escape hatch for when the graphical updater is being conservative and you are not.

Pinning, channels, and jumping versions

Two rules keep upgrades boring, which is the only kind of upgrade worth having. First, back up /userdata/system - your entire configuration - before any major-version jump; minor point releases are safe, but a 43 to 44 leap can deprecate settings and rename keys. Second, never upgrade by re-flashing over a card you care about. Re-flashing wipes /userdata. Re-flashing is for a fresh start or a corrupted system partition; batocera-upgrade and the ES updater are for keeping the machine you already built. Conflating the two is precisely how people lose their save states, and Batocera cannot un-lose them for you afterward.

For readers still weighing Batocera against the obvious alternative before committing a card: RetroPie remains the other name in this space, and it has aged very differently. Our note on RetroPie on PC in 2026 explains why still v4.8, still Ubuntu-only is simultaneously a criticism and, for a certain kind of user who wants a general-purpose Linux box underneath, the entire point.

Six Common Pitfalls

Every one of these is preventable, and every one of them accounts for a disproportionate share of the it-does-not-work posts on every retro-gaming forum in existence. Grouped by the stage they strike at.

Download and image pitfalls

• Wrong architecture. Symptom: nothing boots, or the Pi shows its colour splash forever and never advances. Fix: re-download the image matching your hardware ID - x86_64, bcm2712, bcm2711, or sm8250 - and re-flash. An x86 image on a Pi is not slow, it is inert.
• Counterfeit or failing SD card. Symptom: random freezes, corrupt saves, or a first-boot resize that reports impossible sizes. Fix: verify the card with f3 or H2testw, then replace it. You cannot fight bad hardware with software, and Batocera is not the thing that is broken.

Flashing pitfalls

• Flashed a partition, not the disk. Symptom: an unbootable card after a dd to /dev/sdb1. Fix: flash the whole-disk node (/dev/sdb). You are writing a partition table, so the target must be the disk that holds it.
• Flashed the compressed file without decompressing. Symptom: no boot, because dd wrote a gzip container instead of a disk image. Fix: use gunzip -c file.img.gz | dd, or simply use balenaEtcher, which handles compression for you and removes the failure mode entirely.

First-boot and update pitfalls

• Pulled the card during the first-boot resize. Symptom: a tiny /userdata, strange filesystem errors, or a machine that behaves as though it has almost no storage. Fix: re-flash and let the first boot finish completely and untouched. The resize is not optional and it is not fast to redo.
• Updated by re-flashing and wiped everything. Symptom: all ROMs and saves gone after what you thought was an update. Fix: this one is prevention-only - update with batocera-upgrade or the EmulationStation updater, and re-flash only when you genuinely mean to start over. If you kept a backup of /userdata/system, restore your configuration from it; if you did not, the saves are gone.

Troubleshooting Table

Symptom, likely cause, fix. Work top to bottom; the rows are ordered roughly by how early in the process the fault appears.

Symptom	Likely cause	Fix
Black screen after flashing, no boot at all	Wrong architecture image, or flashed to a partition	Re-download the correct architecture; flash the whole-disk node
Pi shows colour splash then stops	Corrupt or truncated download; card too slow or fake	Re-verify sha256; use an A1/A2 card; re-flash the image
Etcher reports Validation failed	Failing or counterfeit card	Test with f3 or H2testw; swap in a known-good card
Boots, but /userdata shows only 2 to 5 GB on a big card	First-boot resize interrupted, or filesystem error	Re-flash and let the first boot finish; check card health
EmulationStation loads but lists no games	ROMs in the wrong folder, or the list was not refreshed	Place ROMs in /userdata/roms/[system]/; update the game list
Game runs but complains of a missing BIOS	BIOS absent or misnamed in /userdata/bios	Open the BIOS checker menu; match the exact filename and MD5
Network share is not visible on the LAN	SMB name resolution, or the network is not up yet	Connect by IP instead of hostname; confirm networking in ES
In-app updater says up to date but a newer build exists	Wrong channel, or the build is not mirrored yet	Set updates.type=stable; retry later, or use batocera-upgrade with a URL
SSH rejects the default password	Password already changed, or key-only login is set	Use your own password; reset from the local console if needed
macOS dd: Resource busy	The disk is still mounted	Run diskutil unmountDisk /dev/diskN, then flash to /dev/rdiskN

Advanced Tips

Once the basic download-flash-boot loop is muscle memory, these three moves separate a disposable test stick from a machine you actually want to live with.

Run from USB, then install to internal disk (x86)

On x86 hardware, the recommended workflow is to flash to a USB stick first, boot it, and confirm that everything works - video output, controllers, audio, Wi-Fi - before you commit an internal drive. Batocera includes a disk-install path for x86 that copies the running system onto an internal SSD or HDD, giving you a full-speed internal boot instead of a USB one. The exact menu and command have shifted across releases, so consult the wiki's installation page for the current procedure rather than trusting a stale command pasted into a forum three years ago. The principle is durable even when the button moves: test transient, then install permanent.

Pre-boot config with batocera-boot.conf

The FAT32 boot partition holds batocera-boot.conf, a plain-text file read before EmulationStation starts. It is the right place for settings that must exist at boot time - where user data lives, proprietary GPU drivers on x86, headless tweaks. You can edit it from any PC by mounting the boot partition; you do not even need to boot Batocera to change it. Two of the load-bearing keys:

# /boot/batocera-boot.conf  (edit on the FAT32 partition from any PC)
# where /userdata lives: INTERNAL | ANYEXTERNAL | RAM | DEV <uuid>
sharedevice=INTERNAL

# use NVIDIA's proprietary driver on supported x86 GPUs:
nvidia-driver=true

# to split the library onto its own labelled/uuid'd data partition:
# sharedevice=DEV a1b2c3d4-0000-0000-0000-000000000000

The rationale: sharedevice is how you point Batocera at a large second drive for your library while booting the system from a small fast one - the classic small boot SSD plus big ROM HDD split. And nvidia-driver=true is frequently the difference between working output on a modern NVIDIA card and a fallback framebuffer that runs but looks wrong.

Sane defaults in batocera.conf

The main runtime config lives at /userdata/system/batocera.conf. It is where global defaults and per-system overrides coexist, and - unusually for a console-style appliance - it is a readable, diffable, plain-text file rather than a binary blob. Everything you toggle in the UI is written back to this one file, which means backing it up backs up your entire build's personality. The complete-configuration section below is a working, commented starting point you can drop in and edit.

Complete Working Configuration

Here is the payoff: a real configuration you can use, plus a checklist that compresses this entire article into something you can run from memory the second time. Nothing here is aspirational - it is a conservative, boot-it-tonight setup for a 43.1 machine.

A reference batocera.conf

Below is a sane batocera.conf for a 43.1 build: RetroAchievements templated (off until you fill it in), reasonable video defaults, a stable update channel, Wi-Fi ready to complete, and two per-system core overrides as live examples of the syntax. Copy it to /userdata/system/batocera.conf, edit the obvious blanks, and restart EmulationStation.

# /userdata/system/batocera.conf  --  Batocera 43.1 "Glasswing"
# ---- system ----
system.language=en_US
system.timezone=Europe/Paris
system.hostname=BATOCERA

# ---- updates ----
updates.enabled=1
updates.type=stable          # stable | beta  -- stay on stable

# ---- network / share ----
wifi.enabled=1
wifi.ssid=YOUR_SSID
wifi.key=YOUR_WIFI_PASSWORD
# the SMB share ( \\BATOCERA\share -> /userdata ) is on by default

# ---- global emulator defaults ----
global.smooth=1              # bilinear smoothing; 0 = sharp pixels
global.rewind=0              # rewind costs CPU; off by default
global.autosave=0            # auto save-state on exit; off by default
global.shaders=              # e.g. shaders/crt/crt-geom.glslp for a CRT look
global.bezel=default         # decorative bezels around the image

# ---- RetroAchievements (optional) ----
global.retroachievements=0
global.retroachievements.username=
global.retroachievements.password=
global.retroachievements.hardcore=0

# ---- per-system core overrides (examples of the syntax) ----
snes.core=snes9x
n64.core=mupen64plus-next
psx.core=swanstation

# ---- audio ----
audio.volume=90
audio.bgmusic=1

How to read it: global.* keys set a default for every system, while system.* keys such as snes., n64., and psx. override just that one system - and the most specific setting always wins. The per-game overrides you make in the UI land in this same file, appended automatically. Because it is plain text, backing up this single file backs up roughly ninety percent of what makes your build yours; guard it like you would a save.

The download-to-boot checklist

The whole process, condensed to twelve lines you can tick off. Once you have done it once, this is all you actually need:

[ ] 1  Identify architecture: x86_64 | bcm2712 (Pi 5) | bcm2711 (Pi 4) | sm8250
[ ] 2  Download 43.1 from batocera.org/download (direct or torrent)
[ ] 3  Confirm filename: batocera-ARCH-43.1-2026053X.img.gz
[ ] 4  Verify sha256sum (direct downloads; torrents self-verify)
[ ] 5  Verify the card is genuine: f3 (Linux/macOS) or H2testw (Windows)
[ ] 6  Find the target node with lsblk -- WHOLE DISK, not a partition
[ ] 7  Flash: balenaEtcher (easy)  or  gunzip -c ... | dd  (manual)
[ ] 8  Eject cleanly before removing the card
[ ] 9  Boot the target; let the one-time /userdata resize finish
[ ] 10 Load ROMs via the BATOCERA share into roms/SYSTEM/
[ ] 11 Set the update channel to stable; add RetroAchievements if wanted
[ ] 12 Back up /userdata/system/batocera.conf

Where to read the primary sources

For anything this article does not cover, read the source, not the fifteenth reblog of the source. The load-bearing references, all of them primary: the official download page is the canonical image index for both direct and torrent delivery, last updated 2026-08-22; the Batocera homepage carries the Get Batocera.linux 43.1 landing and the project's own description of what it is; the changelog is where 43.1's 2026/05/30 date is authoritative; the torrent index lists the per-architecture files with their exact build dates; and the Updates and Downloads wiki documents the START-menu update path and the batocera-upgrade command. Between those five, every number in this tutorial is traceable to a page you can open yourself - which is the only kind of tutorial worth trusting with a card you are about to erase.