Batocera v43.1 Download: 14 Steps to Flash in 30 Min

Batocera is the rare retro-gaming distribution that does exactly one thing and refuses to apologise for it: it boots a computer or a nano-computer straight into a games console, touches nothing on the host disk, and gets out of your way. The official site calls it "completely free" and "100% open source," and the project's own copyright line reads 2016–2026 — ten unbroken years of shipping disk images from the same address. In 2026 the official download page labels exactly one build the "Current version": v43.1. That is the number you cite, the number you flash, and the number this tutorial is built around.

What follows is a download-and-flash walkthrough in fourteen numbered steps, with a rationale attached to each one because a step without a reason is just superstition. It assumes nothing about your operating system, it tells you which of the several images to actually pick, and it spends real time on the v43-specific landmines — the moved 3DS emulator, the deleted DraStic, the NVIDIA driver line that will hang your upgrade — because the download is the easy part. The thirty-minute estimate is honest for a clean install on decent hardware; it is a polite fiction if you fight Secure Boot for twenty of those minutes, which is why Secure Boot gets its own section.

Why v43.1 Is the Version That Matters in 2026

Glasswing, dated 2026/05/08

The Batocera changelog stamps Batocera 43 with the release date 2026/05/08 and the codename Glasswing. That is the most recent major release marker in the 2025–2026 window, and the downloadable point release riding on top of it is v43.1. If you are reading an older tutorial that tells you to grab v40 or v42, it is not wrong so much as obsolete; the images are still in the wild, but they will offer to update you to 43 on first boot anyway, so you may as well start where the project is. The download page does not hedge: there is one "Current version," and it is this one.

The bundled emulators move too

A point worth internalising before you download anything: a Batocera release is not just Batocera. It is a snapshot of dozens of emulator cores frozen at a particular commit. The v43 changelog, for instance, pins a Xenia (Xbox 360) build at commit 1d7973a dated June 10, 2025. That matters because "download the latest Batocera" is also, implicitly, "download whatever each emulator was on when the image was cut." If a specific core regressed between releases, the fix or the regression travels with the image. This is the difference between Batocera and a package-manager distro: you do not apt upgrade a single emulator, you take the whole curated set or you build from source.

The distribution model is the download

There is no app store here, and the official page makes that structural choice plain: the download links sit directly alongside a "How to Install" block. The primary — really the only — supported distribution path is a direct image download that you write to a USB stick or SD card. The GitHub repository reiterates the philosophy: Batocera turns a machine into a console "during a game or permanently" and requires no modification to the computer itself. Everything in this guide flows from that one design decision. You are not installing software onto an OS; you are writing an OS onto removable media and booting from it.

Prerequisites: Hardware and Software

Hardware you actually need

The floor is low and the ceiling is irrelevant. For a USB-stick "live" setup that leaves the host untouched, you want a flash drive of at least 8 GB, and realistically 32 GB or larger if you intend to store any ROMs on it. USB 3.0 is not optional in spirit — USB 2.0 will boot, but reading a 3DS or PSP title off a 2.0 stick is an exercise in patience you will not enjoy. For an SD-card install on a single-board computer, use a name-brand A1/A2 card; the cheap counterfeits sold in three-packs are the single most common cause of "it boots sometimes" bug reports, and no software fix exists for a card that lies about its own capacity.

On the CPU side, an x86_64 machine from the last decade with 4 GB of RAM runs the 8-bit through 32-bit libraries comfortably. Sixth-generation consoles (GameCube, PS2, Wii, original Xbox) want a modern multi-core CPU and a GPU with current drivers. If you are deciding between a tiny x86 box and a dedicated ARM handheld for this, our breakdown of the 2026 Retroid Pocket lineup covers where ARM silicon tops out versus where you want an x86 image instead.

Software and a second machine

You need exactly two pieces of software on a working computer: a way to verify a checksum (built into every OS) and a way to write a raw image to a block device. The project-blessed flasher is balenaEtcher, which runs on Windows, macOS, and Linux and refuses to write to system disks by default — a guardrail that has saved more home directories than any warning label. Raspberry Pi users can substitute the official Raspberry Pi Imager. Command-line purists on Linux or macOS will use dd, which is faster and exactly as unforgiving as its reputation suggests.

You also need a host computer you are willing to reboot, a wired keyboard for the first-boot menus, and — for an x86 install — access to the BIOS/UEFI setup so you can adjust the boot order and, if necessary, Secure Boot. Have a USB-C or USB-A gamepad on hand; Batocera autodetects most controllers, but a keyboard is the guaranteed fallback when a controller is not recognised in the first sixty seconds.

What you do not need

You do not need a license, an account, a network connection during install, or a second partition carved out of your main drive. You do not need to dual-boot, and you should not try — the whole point of the USB approach is that the host disk is never written to. You do not need BIOS files to install; you need them later, per-system, to run certain emulators, and Batocera stores them in a clearly labelled folder you will meet in the final section. Conflating "install Batocera" with "get every console's BIOS" is the fastest way to overcomplicate a fifteen-minute job.

Which Batocera Image to Download

x86_64 versus x86_64-v3

This is the decision that trips up newcomers, and the v43 changelog answers it directly. For modern PCs and — critically — for x86_64 handhelds with AMD and Intel graphics, the changelog names the x86_64-v3 image as the preferred build. The "v3" refers to the x86-64-v3 microarchitecture level: AVX2, BMI, FMA, and friends, supported by essentially every Intel and AMD chip from roughly 2015 onward. If your CPU is newer than a Haswell-era Core i-series, take the v3 image. If you are flashing for a genuinely ancient machine or a fanless mini-PC with an Atom-class chip that predates AVX2, fall back to the plain x86_64 image, which trades some optimisation for universal compatibility.

ARM boards get their own builds

Single-board computers do not use the x86 images at all. Batocera publishes separate downloads per board family — Raspberry Pi 4 and 5, various Rockchip boards, the Odroid line, and others — and they are not interchangeable. A Pi 5 image will not boot on a Pi 4 and vice versa. The download page presents these as a board picker; choose the exact model name, not "close enough." If you are weighing a single-board console build against a pre-made handheld, our notes on the Miyoo Mini Plus versus the RG35XX are a useful sanity check on whether you want to assemble anything at all.

File format and what you will actually get

Batocera images ship compressed, typically as a .img.gz (gzip) file accompanied by a checksum. Modern flashers — Etcher and Raspberry Pi Imager included — read the compressed file directly and decompress on the fly; you do not need to unpack it first. If you intend to use dd, you will pipe the file through gunzip in the same command, shown later. Do not rename the file to .img and try to flash it; you will write compressed garbage to the stick and spend an hour wondering why it will not boot. The expected download is one compressed image and one short checksum string — nothing else.

Downloading Batocera v43.1, Step by Step

Steps 1–4: Get the right file and prove it is intact

A download tutorial that skips verification is negligent. A corrupted image is the second most common cause of boot failure after counterfeit SD cards, and a one-line checksum check eliminates the entire category.

1. Go to batocera.org and click "get Batocera Linux." The 2026 user funnel is exactly this: the main site, the prominent button, the download page. Rationale: the project distributes only from its own infrastructure; third-party mirrors are where tampered images live.
2. Select your hardware target. For a modern PC or x86 handheld, pick x86_64-v3; for older x86, pick x86_64; for an SBC, pick the exact board. Rationale: the v43 changelog names x86_64-v3 as preferred for AMD/Intel-graphics handhelds, and ARM images are board-specific and non-portable.
3. Download the v43.1 image and note the published checksum. Save both to the same folder. Rationale: you cannot verify what you did not record; the checksum on the page is your ground truth.
4. Compute the SHA256 of the downloaded file and compare. One command, three platforms:

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

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

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

Expected output is a single 64-character hexadecimal string. It must match the value on the download page character-for-character. If it does not, the download is corrupt or tampered — delete it and download again. Do not proceed with a mismatched hash "to see if it works." It will not, and you will not know why.

$ sha256sum batocera-x86_64-v3-43.1.img.gz
3f8a1c... (64 hex chars total) ...e29b  batocera-x86_64-v3-43.1.img.gz

Steps 5–6: Identify the target device, twice

5. Insert the USB stick or SD card and list block devices. On Linux run lsblk; on macOS run diskutil list; on Windows note the drive letter and disk number in Disk Management. Rationale: the flashing step is irreversible and will destroy whatever it writes to. You must know the device node — /dev/sdb, /dev/disk4 — with certainty.
6. Confirm the device by size, then unplug-and-replug to confirm again. Remove the stick, re-run the listing, note which device disappeared, reinsert, note which reappears. Rationale: matching by capacity alone is how people dd their main drive. The disappear/reappear test is unambiguous and takes ten seconds.

$ lsblk
NAME   SIZE TYPE MOUNTPOINT
sda    931G disk            # <- internal drive, DO NOT TOUCH
├─sda1 512M part /boot/efi
└─sda2 930G part /
sdb     29G disk            # <- the 32GB USB stick, this is the target
└─sdb1   29G part

The 29 GB device is the target. The 931 GB device is the machine's life. Internalise the difference before you type another command.

Flashing to USB Stick or SD Card

Steps 7–9: Write the image with Etcher

For ninety percent of readers, balenaEtcher is the correct tool: it cannot write to a mounted system disk without explicit override, it verifies the write automatically, and it handles the gzip decompression itself.

7. Open Etcher and select "Flash from file," then choose the .img.gz you verified. Rationale: Etcher reads the compressed image directly, so feeding it the unpacked file is unnecessary and feeding it a renamed file is harmful.
8. Select the target device. Etcher hides system drives by default; the only device shown should be your stick. Rationale: the default filter is a safety feature — if your intended target is not listed, that is a warning, not a bug to override casually.
9. Click Flash and wait for the verify pass to complete. Etcher writes, then re-reads and compares. Rationale: a write that succeeds but verifies wrong means a failing stick; better to learn that now than at first boot.

Expected Etcher output is a green "Flash Complete!" with a validation checkmark. A red error during validation almost always means the flash media is failing — try a different stick before you blame the image you already checksummed.

The dd alternative for Linux and macOS

If you prefer the command line, dd is faster and pipes through gunzip in one shot. It is also a loaded weapon. Triple-check of=.

# Linux — 'of' is the whole device (sdb), NOT a partition (sdb1)
gunzip -c batocera-x86_64-v3-43.1.img.gz | \
  sudo dd of=/dev/sdb bs=4M status=progress conv=fsync

# macOS — use the raw device 'rdiskN' for speed; unmount first
diskutil unmountDisk /dev/disk4
gunzip -c batocera-x86_64-v3-43.1.img.gz | \
  sudo dd of=/dev/rdisk4 bs=4m

Expected output is a progress counter climbing to the full image size, then a summary line reporting bytes copied and a transfer rate. When dd returns to the prompt, run sync before pulling the stick — the shell prompt returning does not guarantee the write buffer is flushed.

Why the partition-versus-device distinction matters

Writing to /dev/sdb1 (a partition) instead of /dev/sdb (the device) writes the image — which contains its own partition table — inside an existing partition, producing a stick that has a valid-looking filesystem and boots nothing. This is the single most common dd mistake. The image is a complete disk, partition table included; it goes to the whole device. If your of= ends in a digit, stop and reconsider.

First Boot, Secure Boot, and BIOS

Steps 10–12: Boot from the stick

10. Insert the flashed stick into the target machine and power on into the boot menu. The key is usually F12, F11, F8, or Esc, shown briefly during POST. Rationale: you want a one-time boot override, not a permanent boot-order change, until you know it works.
11. Select the USB device from the boot menu. Choose the UEFI entry if both UEFI and legacy entries appear. Rationale: modern Batocera images expect UEFI; the legacy entry may exist but is the less-tested path on current hardware.
12. Let Batocera reach its first-boot setup and detect your controller. EmulationStation loads, scans for gamepads, and drops you at a system list. Rationale: if the controller is not detected, your keyboard arrows and Enter still navigate everything — you are not stuck.

Steps 13–14: Deactivate Secure Boot if it will not boot

This is the practical 2026 setup issue, and the install tutorials call it out explicitly: if the USB drive will not boot, you may need to deactivate Secure Boot in the BIOS. Batocera's bootloader is not signed with a key your firmware trusts by default, so Secure Boot will silently refuse it on many machines — no error, just a fall-through to the next boot device.

13. Enter BIOS/UEFI setup (Del or F2 at POST) and find the Secure Boot option, usually under a "Security" or "Boot" tab. Set it to Disabled. Rationale: with Secure Boot on, an unsigned bootloader is blocked before any Batocera code runs, which presents as "the stick does nothing."
14. While you are there, confirm USB is above the internal drive in boot order, save, and exit. Rationale: once you trust the install, a persistent boot-order entry beats fishing for the one-time menu every reboot.

# Common BIOS paths to the relevant settings (varies by vendor):
Security   > Secure Boot           > Disabled
Boot       > Boot Mode / CSM       > UEFI (leave as UEFI)
Boot       > Boot Option Priorities > USB device first
Advanced   > Fast Boot             > Disabled  (so the USB is detected)

If disabling Secure Boot is not permitted by a managed firmware — a locked-down corporate or school laptop — Batocera is not going to boot from USB there, full stop. That is a deliberate firmware policy, not a Batocera defect. Use hardware you actually control.

Upgrading from v42 Without Losing Saves

Your data survives — by design

The most reassuring fact about a Batocera upgrade, and the most misunderstood, is that Batocera does not delete your data during an upgrade. The upgrade only touches the system and boot partition; user data — games, saves, configs, and BIOS — remains intact on the separate userdata partition. This is why an in-place upgrade from v42 to v43 is genuinely low-risk for your library. It is also why people who "reflash to upgrade" and wipe the stick are doing unnecessary damage: the supported upgrade path preserves everything, the reflash path does not.

Check your /boot partition size first

There is one structural catch with v43 specifically, and the upgrade guidance is blunt about it: check your /boot partition size before updating, because the Batocera image has changed in version 43. Installs created by older versions may have a /boot partition too small to hold the new system image, and the update will fail partway — the worst place to fail. Verify before you commit:

# From the Batocera SSH console (default user 'root', password 'linux')
batocera-es-swissknife --version
df -h /boot

# Example output — watch the Size and Avail columns on /boot:
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       2.0G  900M  1.1G  45% /boot

If your /boot is a few hundred megabytes from an ancient install and the new image needs more, the clean answer is a fresh flash of v43.1 to a new device, then copying your userdata across — not forcing an update into a partition that cannot hold it. A small /boot is the kind of detail that turns a five-minute update into a recovery session.

The NVIDIA 340/390 driver line will hang you

The single most important pre-upgrade action for anyone on older hardware: if you use the legacy NVIDIA 340 or 390 drivers, you must remove or comment out the nvidia-driver line in batocera-boot.conf before updating. Those legacy driver branches are not carried forward, and leaving the line in place sends v43 looking for a driver that no longer exists — which presents as a hang or a black screen on first boot after the update.

# Edit /boot/batocera-boot.conf BEFORE upgrading.
# Find the legacy driver directive and comment it out:

# nvidia-driver=true      <- comment this out (legacy 340/390 only)

# Leave it commented; v43 will select an appropriate default driver.

If you are on a GPU new enough for the current mainline NVIDIA driver, this does not apply to you — the warning is specifically about the 340 and 390 legacy branches. But if your card is that old, ignoring this is the difference between a working upgrade and a dark screen.

Five Pitfalls That Brick the Boot

Pitfall 1: Encrypted 3DS ROMs after the Azahar switch

Batocera v43 changes the Nintendo 3DS emulator path, moving to Azahar — the successor that absorbed the Citra lineage. The consequence is concrete and breaks existing libraries: ROMs must be decrypted, because encrypted CIA or CCI files are no longer supported. If your 3DS folder is full of encrypted dumps that worked on v42, they will fail silently on v43. Fix: decrypt your dumps to a supported format before moving to v43, and keep them in the 3ds system folder. See the Azahar project repository for current format support; do not assume a file that launched last year still launches.

Pitfall 2: Expecting DraStic to still be there

The v43 guidance removes DraStic — the long-serving Nintendo DS emulator — because it is closed source, and there is no direct replacement for old DraStic saves. This is a genuine compatibility wall for legacy DS users: your save data is tied to a tool that is no longer in the image, and the open-source DS cores do not read DraStic's save format one-to-one. Fix: if you have irreplaceable DraStic saves, archive them and consider keeping a v42 install on a separate stick specifically for DS, rather than expecting v43 to honour them. Closed-source removals are a recurring theme in open distros, and the only real defence is keeping the old image around.

Pitfall 3: Flashing the partition, not the device

Covered above and worth repeating because it is the most common dd failure: writing to /dev/sdb1 instead of /dev/sdb produces a non-booting stick that nonetheless mounts and looks fine. Fix: the of= target must be the whole device with no trailing digit. If you used Etcher you are immune to this; if you used dd, re-read your command before running it.

Pitfall 4: Counterfeit SD cards

A card that reports 256 GB but physically holds 16 GB will flash without error and corrupt the moment writes wrap past the real capacity. Fix: validate new cards with a capacity tester (H2testw on Windows, f3 on Linux/macOS) before flashing anything you care about, and buy from sources that are not optimised purely on price. No amount of correct flashing fixes a card that lies.

Pitfall 5: Renaming .img.gz to .img

Stripping the .gz off the filename does not decompress it; it just removes the hint that tells your flasher to decompress. Write the still-compressed bytes to a stick and it boots nothing. Fix: leave the filename intact and let Etcher or the gunzip -c | dd pipeline handle decompression. If you genuinely want a raw .img, decompress it with gunzip first — the rename alone does nothing useful.

Troubleshooting Table

Boot and flash failures

Most first-time failures cluster around boot detection and media quality. Work top-down: confirm the media is good, confirm the firmware will boot it, then confirm the image is intact.

Symptom	Likely Cause	Fix
USB stick does nothing at boot	Secure Boot blocking unsigned loader	Disable Secure Boot in BIOS Security tab
Machine boots to internal drive, ignores stick	Boot order or Fast Boot	Set USB first in boot priority; disable Fast Boot
Stick boots intermittently	Counterfeit or failing flash media	Test with f3/H2testw; replace the card
"Flash Complete" but no boot	Image written to partition, not device	Re-flash to /dev/sdX, no trailing digit
SHA256 mismatch on download	Corrupt or tampered image	Delete and re-download from batocera.org
Black screen after v42→v43 upgrade	Legacy nvidia-driver line in boot.conf	Comment out nvidia-driver in batocera-boot.conf
v43 update fails partway	/boot partition too small for new image	Check df -h /boot; fresh-flash if undersized
3DS games no longer launch	Encrypted CIA/CCI; Azahar needs decrypted ROMs	Decrypt dumps to supported format
DS saves missing after upgrade	DraStic removed (closed source)	Keep a v42 stick for DS; archive saves
Controller not detected at first boot	Unsupported pad or timing	Use keyboard arrows/Enter; configure pad in menu

Reading the symptom honestly

The discipline here is to match the symptom to the layer it actually lives in. "Does nothing at boot" is a firmware problem ninety percent of the time — Secure Boot, boot order, Fast Boot — not an image problem, so do not re-download the image to fix it. "Boots sometimes" is almost always media. "Boots, then a specific system fails" is emulator-level — the Azahar and DraStic rows — and has nothing to do with the install. Triaging by layer saves you from re-flashing five times to fix a BIOS toggle.

Advanced Tips for the v43 Era

SSH in and use the swissknife

Batocera ships an SSH server. From any machine on the network, ssh root@batocera with the default password linux drops you into a console where batocera-es-swissknife is the maintenance multitool — restart EmulationStation, regenerate game lists, report the running version. Change that default password immediately if the box is on a network you do not fully trust; "root/linux" is a published default, which makes it a published vulnerability the moment the device is reachable.

# From your desktop:
ssh root@batocera           # password: linux (CHANGE THIS)

# Useful one-liners once connected:
batocera-es-swissknife --version     # confirm you're on 43.1
batocera-es-swissknife --restart     # restart EmulationStation
batocera-save-overlay                # persist system changes to disk

Match emulator config to RetroArch's documentation

Most of Batocera's emulation runs through libretro cores under RetroArch, and per-system tuning — shaders, run-ahead latency reduction, core options — is documented far better upstream than in any third-party guide. When a specific core misbehaves, the libretro documentation and the RetroArch site are the authoritative references for what each option actually does. Batocera exposes these as per-game and per-system overrides in its own menu; the upstream docs tell you which knob to turn before you start turning them blind.

Keep the old image; consider the alternatives

Because v43 removed DraStic and changed the 3DS path, the pragmatic move for a legacy-heavy library is to keep a v42 stick labelled and shelved. It costs one cheap USB drive and saves you from a one-way upgrade you cannot fully undo. And if Batocera's whole-image model does not suit you — you want package-level control, or you are on hardware Batocera does not target — it is worth knowing the neighbours: our look at RetroPie on PC in 2026 and the related rundown of why there is still no official RetroPie PC release lay out where a Debian-based stack beats a sealed image and where it very much does not.

A Complete Working Configuration

The batocera-boot.conf that survives v43

Everything above converges on one file and one folder layout. Here is a complete, commented /boot/batocera-boot.conf tuned for a clean v43.1 install on modern x86 hardware — no legacy NVIDIA line, sensible defaults, ready to boot.

# /boot/batocera-boot.conf — Batocera v43.1 (Glasswing), x86_64-v3
# Lines beginning with # are comments and are ignored.

# --- Display ---
# Leave video output on auto unless you have a stubborn screen.
# vout=auto

# --- GPU driver ---
# DO NOT enable the legacy 340/390 NVIDIA line on v43.
# It is removed upstream and will hang the boot.
# nvidia-driver=true        # <- intentionally left commented

# --- Boot behaviour ---
# Run EmulationStation immediately at boot (default).
# Set to 0 only if you want to drop to a console.
# button.shutdown=true

# --- Userdata location ---
# 'auto' keeps games/saves/BIOS on the separate userdata partition,
# which is what survives an in-place v42 -> v43 upgrade untouched.
sharedevice=auto

# --- Networking (optional) ---
# Enable SSH for remote maintenance. Change the root password!
# wifi.enabled=0

The folder layout you will actually use

On the userdata partition, Batocera lays out a predictable tree. ROMs go under roms/<system>, BIOS files go in bios, and saves live alongside. This is the layout that the upgrade preserves and that the SSH console exposes.

/userdata
├── bios/                 # per-system BIOS files (e.g. PS1, Saturn)
├── roms/
│   ├── snes/             # Super Nintendo ROMs
│   ├── psx/              # PlayStation 1 images + matching BIOS
│   ├── 3ds/              # DECRYPTED 3DS dumps only (Azahar, v43)
│   └── nds/              # DS — note: DraStic removed in v43
├── saves/                # save files and states
└── system/
    └── batocera.conf     # global + per-system overrides

A minimal batocera.conf override set

Finally, a small set of global overrides in /userdata/system/batocera.conf that most installs benefit from — a reasonable default emulator behaviour, retroachievements off until you opt in, and a sane global shader. Adjust per-system using the values documented upstream at libretro.

# /userdata/system/batocera.conf — selected global overrides

# Show FPS overlay globally (turn off per-system if distracting)
global.showFPS=0

# Smooth bilinear scaling globally; override per system for CRT shaders
global.smooth=1

# RetroAchievements off by default — enable + add credentials to use
global.retroachievements=0

# Run-ahead off globally (enable per-system for low-latency 2D cores)
global.runahead=0

# Example per-system override: CRT shader for SNES only
snes.shaderset=scanlines

That is the whole job: pick the v43.1 image that matches your hardware — x86_64-v3 for anything modern, the board-specific build for an SBC — verify its checksum, write it to the whole device, disable Secure Boot if the firmware sulks, and keep your /boot partition and legacy drivers in mind if you are upgrading rather than installing fresh. Batocera asks for no license and modifies nothing on the host; the only things standing between a download and a working console are a correct device node and a BIOS toggle. Everything past that — the cores, the shaders, the per-system tuning — is documented upstream and waiting. The download was always the easy part. Now you know which version, which image, and which v43 traps to step around.