Skip to content
RetrogamingHow-To Published Updated 4 min readViews unavailable

Lakka Storage and Upgrades: Preserve the Writable State, Replace the Right Image

Understand Lakka's read-only root and persistent storage, choose a board-matched release, back up saves and configuration, and validate an upgrade safely.

Lakka packages RetroArch as a console-oriented Linux distribution. It is not just a desktop RetroArch install: the system image, hardware target, read-only root, persistent storage, and update mechanism all affect what survives maintenance. Treat the OS image and your collection as separate recovery assets.

The project released Lakka 6.1 in February 2026, but that is not a reason to install an image merely because its version number is highest. Check the official release list and download page for a build that explicitly matches your board and architecture. A successful download does not establish that the image supports your hardware revision or chosen video driver.

Map persistent storage before changing anything

Lakka’s documentation describes the root filesystem as read-only. Changes to assets, cores, and other root-provided files use an overlay mechanism rather than ordinary permanent edits to the base image. User data lives under the persistent storage area, commonly exposed at /storage; documented directories include ROMs, System files, save files, save states, playlists, thumbnails, overlays, and update files.

Before upgrading, inspect the active RetroArch directory settings instead of assuming a guide’s paths match your installation. A customized retroarch.cfg may redirect saves, system files, playlists, or content to another path. Record those effective paths, and keep native save files separate from save states. A save state is a snapshot tied to emulator implementation details, not a durable substitute for the game’s own save format.

Build a complete backup set

Copy the persistent data you actually use, not only the visible ROM directory. At minimum, inventory:

  • Native save files and any save states you still need.
  • RetroArch configuration, playlists, controller remaps, shaders, overlays, and thumbnails.
  • Firmware/system files you are authorized to retain, together with hashes and provenance notes rather than copies in public support material.
  • Logs, network/service configuration, and any custom data stored outside the standard folders.

Keep a read-only recovery copy on another device. If the backup crosses operating systems, check that hidden files and directory structure were preserved. Hash important saves and configuration before and after transfer, and open a representative file from the backup. A backup that has never been read back is only an assumption.

Upgrade through the matching release channel

For the ordinary path, use the Lakka graphical Online Updater’s Update Lakka entry, choose the image for the exact hardware, wait for the download, and reboot only after the updater completes. The project also documents placing a matching update image in the storage update directory and a PC-specific USB installer route. Those are alternatives with different failure modes; do not mix their steps.

The current GitHub release page is the authoritative place to check published stable release assets and their checksums. Use the hash file supplied with the exact asset when available, and compare the correct algorithm and exact filename. Do not use an image for a different board, nightly, or development archive as an unreviewed substitute for a stable release.

Lakka’s upgrade documentation warns that system/kernel updates do not necessarily migrate every RetroArch configuration path. Before a major version change, read the current release notes and take the backup above. Do not reflexively delete retroarch.cfg because an old troubleshooting snippet says to; first compare the active paths and preserve a copy. Reset only a specific setting or configuration file when the release documentation or a reproducible failure justifies it.

Reflash only after treating it as destructive

A clean install can be the safer route for a major upgrade, but flashing overwrites the selected target. Identify the removable device by capacity and device identity, unmount it cleanly, and verify the target again immediately before writing. Keep the prior card or image unchanged until the new installation boots and the backup has been tested.

On first boot, confirm the reported Lakka build and the expected controller, display, audio, and network behavior before restoring the full collection. Restore a small test set first. Verify that the expected playlist launches the expected core, firmware status is consistent with that core’s official documentation, and the game can make and reload a native save after a clean restart. Then restore the rest of the configuration in small groups so a stale path or old overlay does not obscure the cause of a failure.

Keep the appliance’s trust boundary small

Lakka’s simplicity comes from a purpose-built image. Do not install random system packages into the base operating system or copy replacement cores from unrelated builds. Use the project’s release/update mechanisms and the package source associated with the image. Keep network services disabled when they are unnecessary, never expose remote administration directly to the public internet, and sanitize usernames, addresses, firmware, and game data from logs before sharing them.

You can call the migration complete when the installed build matches the target hardware, the persistent data has an independent verified copy, playlists resolve to the intended content and cores, controllers/audio/video work, and a native save survives reboot. Keep the old image and backup until those checks pass.

Related:

Sources:

Comments