RetroPie / RetroPie/RetroPie-Setup
Using the latest Amiberry/Amiberry-Lite versions, in Bookworm
Nobody has claimed this yet.
- Dominant language
- Shell
- Stars
- 10.4k
- Forks
- 1.4k
- Avg merge
- 2d 12h
- Merged PRs (30d)
- 11
Description
Hi all,
In order to troubleshoot an issue reported to me recently (https://github.com/BlitterStudio/amiberry/issues/1617), I went through the process of installing RetroPie on top of an RPI-OS Lite installation, running Bookworm, on an RPI5.
I wanted to document the changes I did for the latest Amiberry to run on it, in the hopes that it could help you in the migration at some point and minimize any pains. Feel free to adapt things according to your needs, of course. These steps aimed to keep things in place as much as possible, so you can certainly make it even cleaner (e.g. you don't need to install the old Amiberry first, like I did).
The newer Amiberry and Amiberry-Lite releases are packaged into DEB and RPM installers. This is the easiest way to install them, if you're running one of the supported OS versions (Buster is out of support, so this will only work for Bullseye and Bookworm). It will bring in any dependencies for you, so you don't need to do that beforehand. It can also be uninstalled or upgraded, using standard syntax (e.g. sudo apt remove amiberry will do what you expect).
I installed Amiberry as follows:
- Installed the old (5.7.2) Amiberry from source, using the RetroPie-Setup. This wasn't necessary, but it just helped setting things up originally, such as the symlinks to the paths, which I looked at in order to configure things in the next steps.
- Used the relevant
.debpackage (bookworm, arm64) to install Amiberry and any dependencies (flac and libenet were missing). - Renamed the RetroPie-installed older
amiberrybinary in/opt/retropie/emulators/amiberry, toamiberry.572. Just as a precaution, to make sure that does not run by mistake. - Edited
amiberry.shto runamiberry, instead of./amiberry, so it can find it from the different location the DEB installed it in (system wide). - Then I run Amiberry from the console once, to let it create the default directory structure and
amiberry.conffile, which is created by default under XDG_CONFIG_HOME (~/.config/amiberry/amiberry.conf) - After that, I edited the
amiberry.conffile, to change some of the paths, so they point to RetroPie's. Those were:
controllers path -> /opt/retropie/configs/all/retroarch/autoconfig
retroarch_config -> /opt/retropie/configs/all/retroarch/retroarch.cfg
rom_path -> /home/pi/RetroPie/BIOS/amiga/
I left the rest of them at their defaults, as there was no reason to change them for now. You might want to change the floppy_path, cdrom_path, whdload_arch_path as well, perhaps.
Saved, restarted EmulationStation, and launched Gods_v3.2_0666.lha from there. It correctly used the newer Amiberry to run it, and I let it go all the way into the game.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the RetroPie-Setup Amiberry entry point and the amiberry.sh script, then compare their current paths with the Bookworm and arm64 steps described here. Check how the DEB-installed binary and XDG configuration are handled. Done means the supported migration guidance is recorded accurately and can be followed on an RPI5 running Bookworm.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- debian, raspberry-pi, shell
- Domain
- devops, documentation
- Issue type
- Documentation
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100