· None of the above quite fits
· None of these quite match
· RonnBridge on Linux actually needs glibc 2.34 or newer
· not relevant
It looks like you are running ARM with a 32-bit OS. What device and OS are you running?
Thanks for sharing that screenshot and the note about RoonBridge on Linux needing glibc 2.34 or newer. Could you confirm the device you are using, along with the OS version? Thank you.
It is Volumio 3.912 on a Raspberry Pi 4.
This has glibc 2.28 installed and should have been able to run the new RoonBridge according to the minimum required version 2.27 advertised by Roon in the release notes.
So either the release notes are incorrect and need to be updated or the installer checks for a higher glibc version than actually needed and has to ne fixed.
Based on Roon only officially releasing the update with the greater requirements yesterday, I’d at least give them a few days to update their website.
They have had this announced a while ago about the new requirements.
The issue I see you have is Volumio 3 not supporting Roon Bridge anymore.
It looks like you are running a 32-bit OS on 64 bit hardware, so the minimum requirement is not 2.27.
Consequently, it is unlikely that Volumio 3 can run the latest version of Roon Bridge. You will need to update to Volumio 4.
It has been out in EarlyAccess for almost 3 weeks now, see …
https://community.roonlabs.com/t/early-access-roonbridge-1684-net10-update-is-live/323815/2
According to the click counter next to the download links, nobody tried out the ARMv7 version. So the issue of different minimum glibc version requirements for 32bit environments most likely slipped through.
Thanks for the additional information @Roland_von_Unruh, we’ve got a ticket in with development for closer inspection.
Thanks for your patience in the meantime!
As it seems, all ARM versions (v6, v7, v8) need at least glibc 2.34 while the 2.27 minimum requirement only applies to x64-architectures.
See the following excerpt from the “check-common.sh” shell script of the RoonBridge installer:
display_check "Checking for a supported glibc version"
local need
case "$(uname -m)" in
armv7l|armv6l|armv8l|arm) need="2.34" ;;
aarch64|x86_64) need="2.27" ;;
*) display_ok; return ;;
So all it takes for Roon is to update their release notes with the architecture specific details.
I have a rather similar issue with an Allo USBridge (the old version with Sparky cpu). start.sh complains:
Checking for a supported glibc version [ FAILED ]
This system has glibc 2.31; the bundled .NET runtime requires glibc 2.34 or newer.
Please upgrade the OS (Debian 12 Bookworm / Raspberry Pi OS Bookworm or newer).
The DietPi version is 9.20.2. The problem with this device is that DietPi dropped support for this architecture after versio 9 (no new kernel available) and upgrade is not possible. Just for your information.
The oversight is related to 32-bit systems where glibc version numbering differs to the 64-bit variant, which is widely used. The RPi 3B+ onward all support a 32 bit architecture.
Unfortunately, it seems that no one in EA uses a 32-bit OS nowadays.
Moreover, this appears to affect unsupported OS only, e.g. Volumio 3 and DietPi 9.
glibc minimum for .NET 10
32-bit 2.34
64-bit 2.27
The whole confusion could have been avoided, if the Roon staff had provided detailed and correct information about minimum requirements in the first place.
After all, someone at Roon must have written the above shell script that checks for different versions of the glibc library depending on system architecture, so it must have been well known by Roon. If you take a close look in the check-common.sh script, you’ll find a remark (#) block with detailed explanations why the different glibc versions need to be checked on different system architectures as well. So this doesn’t come as a surprise for Roon, instead it seems to have been clear right from the beginning.
IMHO Roon staff needs to take responsibility here to have led several users of older hardware into the false belief, updating the device would be possible and leaving them with non-functional devices instead.
the best thing Roon could do now would be to provide links to download and install the previous build of RoonBridge so those people can revive their devices and stay on the older version of RoonBridge for the time being.
See here:
This is about the missing information on the libicu-dependency.
I was talking about the false information given by Roon regarding minimum glibc requerirements on different systems.
I agree to a point, but it is also our responsibilty to maintain our systems, and it would seem, that the systems affected are unsupported by their respective distros.
Moreover, the move to .NET 10 wasn’t a surprise, and community identified the issue very early. The dependency was advertised, and whilst this differs between 32 and 64 bit, I wonder how many actually checked that they were running a supported version or just blindly updated.
As already pointed out, no one tested the arm7hf or a 32 bit OS, probably because most of us have moved on. I think it is quite reasonable to expect some things to get missed when there is complexity.
I also think Roon listened to feedback after the server / app release for .NET 10, and have improved communication.
Storm in a teacup.
@Stephen To my understanding, when an APP update is triggered from the RoonRemote, RoonBridge & RoonServer 's start.sh script is used with parameter --update . As part of that if branch in the script we should not promote the new SW version (by renaming "$ROOTDIR/.update.tmp" to "$ROOTDIR/.update") if "$ROOTDIR/.update.tmp"/check.sh fails
I checked for glibc compatibility and should have been safe according to the release notes (2.27 required, 2.28 installed). Other users reported to have done the same.
Also Roon officially offers two Linux arm versions for download, the armv8 being the one to be used on 64bit RasPi OS, that also needs a higher glibc version than advertised.
I was able to move from Volumio OS 3 to 4 (which has it’s own flaws in my specific setup using the MetaRoon and FSCT plugins). Others might not have an update option for their specific hardware and probably would have avoided the update if correct Information had been provided right from the start.
But i agree it’s a first world problem and there are more important things out there.