Hello I am trying to install the new Bridge version. As per release notes the glibc and openssl libraries are on the correct level. However the install script contradicts the glibc version requirement documented on the release notes and refuses to proceed.
Release notes requirement: glibc 2.27 (I have 2.28)
Install script fails validation because it is requiring version 2.34 on install
now my bridge functionality is dead.
New Bridge wonāt run on DietPi. Two Endpoints have vanished after running the update. Yes, glibc and OpenSSL surpass the requirements. Bridge is installed, but āhtopā shows itās not running. This needs to be fixed quickly.
Roon Bridge 2.71 (build 1683) production running fine here in DietPi.
DietPi v10.6.2 Trixie running on Raspberry Pi 4b.
root@BedroomPi:~# uname -a
Linux BedroomPi 6.18.39+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.18.39-1+rpt1 (2026-07-29) aarch64 GNU/Linux
root@BedroomPi:~#
All packages kept up to date using 'apt update && apt upgrade" as of 18 hours ago.
root@BedroomPi:~# openssl version
OpenSSL 3.5.7 9 Jun 2026 (Library: OpenSSL 3.5.7 9 Jun 2026)
root@BedroomPi:~# ldd --version
ldd (Debian GLIBC 2.41-12+rpt1+deb13u3) 2.41
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.
root@BedroomPi:~#
Update from the āaboutā page of Roon Settings in the Roon Client app without issues.
Are you running Trixie or are you still on bookworm?
All my DietPi endpoints were updated to Trixie in August 2025 using the instructions at:
I also keep my DietPi installation up to date using ādietpi-updateā whenever a new DietPi release is announced
I managed to solve the issue by installing Docker and creating a bookworm container for the new Roon Bridge.
The only issue I had implementing this solution was the Volumio kernel didnāt allowed the container to access the network and the DAC. I solved it by recreating the container as privileged.
As reference: My Volumio device is the old Primo V1 that canāt be upgraded to the newer 4.x version so getting more up to date packages would not be possible (manual package upgrades might be possible but it will risk the whole system stability).
I just tried to update RoonBridge on a fourth Raspberry Pi running DietPi and it failed. Looking at the log, I saw that there was an unresolved dependency on libicu.
On this particular DietPi installation, libicu was not installed. Without looking deeper, I canāt say why it was installed on the other three DietPi installations and not this one - obviously another package installed on the other three Raspberry Piās (but not on this one) has libicu as a dependency. It maybe because the other three Raspberry Piās are running Audio HATs of one type or another but this one is just using a USB connected DAC.
Anyway, I was able to resolve this issue manually:
root@PiHeadphone:~# apt install libicu76
Installing:
libicu76Summary:
Upgrading: 0, Installing: 1, Removing: 0, Not Upgrading: 0
Download size: 9524 kB
Space needed: 38.4 MB / 57.5 GB availableGet:1 Index of /debian trixie/main arm64 libicu76 arm64 76.1-4 [9524 kB]
Fetched 9524 kB in 1s (9542 kB/s)
Selecting previously unselected package libicu76:arm64.
(Reading database ā¦ 23300 files and directories currently installed.)
Preparing to unpack ā¦/libicu76_76.1-4_arm64.deb ā¦
Unpacking libicu76:arm64 (76.1-4) ā¦
Setting up libicu76:arm64 (76.1-4) ā¦
Processing triggers for libc-bin (2.41-12+rpt1+deb13u3) ā¦
root@PiHeadphone:~#
It looks like libicu is a new dependency that is not catered for by the RoonBridge update.
There was also an undocumented dependency on RoPieee today, which is now fixed.
Iāll check Ubuntu hosts later today.
This is crazy after the download my rasberry pi endpoint running Vitos has vanished when is this getting fixed
Okay, Ubuntu 24.04 ships with libicu74, which is a dependency for .NET 10, so no problem there. For those running Ubuntu 22.4 or earlier, the package needs installing with dpkg and dependency errors fixed with APT.
Thatās for you to do. Install libicu74 since this is a dependency for .NET 10.
I think this is where some will disagree, but the need for a certain dependency for the vendors software update should have been recognised by the update that it didnāt meet the requirement and therefore should have downloaded the correct version.
An app cannot install these dependencies, which is why there is a minimum OS requirement for macOS, and dependencies for Linux. Linux users should keep their systems up-to-date wherever possible. If this is too much trouble for running Roon Bridge, then use a turnkey solution such as Ropieee, which Harry fixed early today.
I have notified Roon staff about the dependency, but this is more about communication than anything else.
Looks like Iāll have to consider switching from DietPi to RoPieee. I have a number of RPiās ranging from 3B, 3B+, and 4B that I reflashed with ābookwormā sometime last year.
I upgraded two of them with the new Bridge, but htop shows Bridge isnāt running. Someone on here suggested I update to the latest version of DietPi, and that should fix it, but no luck - Bridge is installed but not running. I uninstalled/reinstalled Bridge, but still no luck.
I feel bad for all the subscribers that took Roon at face-value stating Raspberry Pi users would be fine as long as you had āglibc 2.27 or laterā and āOpenSSL 1.1.1 or laterā. Obviously there are other configurations that went untested.
On the rare times Roon updated Bridge in the past, it was seamless and error free. I understand the change made this time is far different, but without proper requirements listed for error free upgrade, countless subscribers are left with no Endpoints.
Fortunately I have a couple spare RPi 4Bās with a working version of Bridge installed. Iāll depend on these until Roon sorts this out. With eight RPiās that need upgrading, I hope I wonāt need to switch to RoPieee on all of them.
Cheers.
I was the one that suggested DietPi ran Roon Bridge 2.71 fine - but I later found that on just one of my four DietPi installs, libicu was missing.
I fixed this, as I reported earlier using:
sudo apt install libicu76
I was then able to start the Roon Bridge service using:
sudo systemctl start roonbridge.service
If you are logged in as root, then āsudoā can be omitted.
In either event, it is an easy fix.
Same for me. Luckily I had backed up my Dietpi10.5.2 version so restored along with the old version of Roon Bridge and it is running. I could not update Roon Bridge as fails to run on either 10.5.2 or 10.6.2. I tried updating to 10.6.2 and the latest Bridge version installs but does not run. I checked the dependencies as required and shows ok.
root@DietPi:~# ldd --version
ldd (Debian GLIBC 2.41-12+deb13u3) 2.41
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.
root@DietPi:~# openssl version
OpenSSL 3.5.6 7 Apr 2026 (Library: OpenSSL 3.5.6 7 Apr 2026)
Update - upgraded again to 10.6.2 then installed libicu76 then reinstalled roonbridge (121) and all good.
Thank you Wade_Oram (mine was not HAT just ALSA ā USB Vega DAC as your instance that needed the install)
@Wade_Oram , thanks, Iāll try it. And I understand itās an easy fix. But Iāve supplied over 150 Roon subscribers with an RPi Endpoint, many long before I ever heard of RoPieee.
My point isnāt ācan I get Neil up and runningā. My point is Roon =should= have made this upgrade transparent to the user, with no involvement needed on their part. Iām trying to help others get their music streaming again.
Thanks.
@Wade_Oram , ldd (Debian GLIBC 2.36-9+rpt2+deb12u14) 2.36
and:
OpenSSL 3.0.20 7 Apr 2026 (Library: OpenSSL 3.0.20 7 Apr 2026)
The start cmd ran, but didnāt work (I had tried it last night with the same result). Bridge (still) isnāt running. I appreciate the suggestions, but Iād really prefer Roon solved this with a proper Bridge upgrade for RPiās.
My best.
I agree. Roon messed up. They missed this new dependency (or at least the fact that a compatible version of libicu is not always installed) and should have done better. It is particularly annoying since they encountered the same issue on some systems when the Roon Server migrated to .Net 10 so they should have been aware of it.
However, when faced with the issue, it only took me two minutes to fix it.
Look at the RoonBridge start up logs to identify that there was an unsatisfied dependency on libicu.
Determine what package to install:
apt list libicu*
This showed that libicu76 was available (at least on trixue) but was not installed.
Install the package:
apt install libicu76
Start the service
systemctl start roonbridge.service
You donāt have to perform steps 1 and 2 because I have done the work for you. But you do need to do both steps 3 and 4 in order to get Roon Bridge working.
It is not the glibc or libssl versions that are causing the problem. It is a new dependency on the libicu library. The apt install command at step 3 above fixes the missing library.
If libicu76 is not available on bookworm, you can use the apt list command in step 2 to find out what version is available and install that version.
They missed a dependency that is not present in recent distros. It is likely that they never saw this, and nor did EA, and it would be unreasonable to expect Roon to check every distribution across multiple versions.
Nonetheless, Roon cannot make this upgrade ātransparentā since apps that are installed without the package manager should not, under any circumstances, change the system. Even so, if Roon did use the package manager, it would fail if the repo didnāt have a required version.
@Wade_Oram, AFAICS libicu74 is fine, too. Confirmed on Ubuntu 24.04.
Actually, the install script does check.
Checking to see if RoonBridge can run on this machine
Checking for a supported glibc version [ OK ]
Checking for Binary Compatibility [ OK ]
Checking for libstdc++ [ OK ]
Checking for libicu [ OK ]
Checking for ALSA Libraries [ OK ]
STATUS: SUCCESS
The logs are our friend.