I have a problem updating my ROCK core on an Intel NUC and I am stuck in an update loop.
Hardware: - Intel NUC10i5FN - Internal SSD used for ROCK OS and Roon database
BIOS: - Configured according to your guide: https://help.roonlabs.com/portal/en/kb/articles/rock-updating-and-configuring-bios-on-your-nuc (Section 2 – Essential Settings Configuration for NUC10)
Installation: - I downloaded the latest standard ROCK installer image from your website (not the “emergency” recovery image). - I wrote it to a USB drive and installed ROCK from scratch. - Installation finished successfully.
Current status in the ROCK Web Administration Interface: - Operating System: Version 1.0 (build 258) – OK - Roon Server Software: Version 2.0 (build 1234) production – OK - Roon Database & Settings: OK
Network settings of ROCK: - Static IP: 192.168.2.68 - Netmask: 255.255.255.0 - Gateway: 192.168.2.1 - DNS Server: I tried 192.168.2.1 (router), 1.1.1.1 and 8.8.8.8 – no difference. - ROCK is reachable from my PCs via Web UI (http://rock or http://192.168.2.68) and via SMB share \\rock\data.
Roon client: - Windows 11 PC - Roon 2.56 (build 1582) production - The client says that a software update is required and shows this screen:
“Roon Optimized Core Kit – 2.0 (build 1234) production – Downloading…” “This PC – 2.56 (build 1582) production – Latest version installed.”
- The “Downloading…” status for the Core never finishes and I cannot connect to the core.
When I try to reinstall/update from the ROCK Web UI, after some time I get this error:
“There was an error downloading Roon. Please check your internet connection. {"status":"Failure","exitcode":11}”
My internet connection is working fine in general: - From the same Windows 11 PC I can open https://download.roonlabs.com and the Roon client updates to 2.56 (build 1582) without any issues. - Only the ROCK core cannot download its update.
It looks like ROCK cannot reach your update servers for some reason, and therefore the core is stuck on build 1234 while the client requires a newer build.
Could you please help me with:
1) Explaining what exact URLs / domains ROCK uses to download updates, so I can check connectivity from my network, and 2) Providing a way to update the ROCK core to the current production build (compatible with Roon 2.56 build 1582), or any manual/offline procedure if such exists?
I can provide screenshots and logs from ROCK if needed.
Roon endpoints/DAC chain is local USB from ROCK → Topping D90SE → Topping A90 (headphones); not using networked endpoints for this issue
Control devices: [Android/PC/], typically on 5 GHz Wi-Fi from the same router
Switches (if any): [ unmanaged]; no VLANs/PoE configured
LAN details:
Subnet 192.168.1.0/24; DHCP served by router (static lease reserved for ROCK or manual static as above)
No Pi-hole/AdGuard Home, no custom firewall rules blocking outbound 80/443
Cables Cat5e/Cat6; link speed 1 Gbps; link is stable (no errors/drops observed)
Symptoms context:
After emergency reinstall to RoonOS 1.0 (build 258), Web UI offers update to RoonOS 2.0 (build 1234) but it never completes (“Updating and Reinstalling” spins).
Internet access from other devices is normal; Qobuz app works directly. Issue seems limited to ROCK fetching the OS update.
I think this is your issue given the router settings described:
The ip address assigned to the ROCK Roon Server is not within the subnet managed by your router.
The ROCK ip address should be set to 192.168.1.x and the gateway should be set to the lan side ip address of your router - probably 192.168.1.1 or 192.168.1.254
The misconfigured static ip address and gateway would explain why ROCK can apparently not find the Roon upgrade servers when other devices on your network can.
Also, if you have your ROCK server configured to a static ip address, that ip address, whilst within the same subnet, must be outside of the ip address pool that DHCP on the router is configured to use and you should not have a DHCP ip address reservation.
Alternatively, you can set the ROCK to use DHCP and then use a DHCP reservation (set to an ip address within the 192.168.1.0/24 subnet) to ensure that the ROCK device always gets the same ip address. This way of setting up is much less likely to cause issues in the future.
The subnet information in my earlier post was my mistake when I typed the example – the ROCK has always been in the same subnet as its router. I actually tested the ROCK in two different locations / networks:
Location A
LAN: 192.168.1.0/24
Router (LAN IP / gateway): 192.168.1.1
ROCK: 192.168.1.100
Gateway on ROCK: 192.168.1.1
DNS: router IP, and I also tried 1.1.1.1 and 8.8.8.8
I used either a static IP outside the DHCP pool or a DHCP reservation for 192.168.1.100.
Location B
LAN: 192.168.2.0/24
Router (LAN IP / gateway): 192.168.2.1
ROCK: 192.168.2.68
Gateway on ROCK: 192.168.2.1
DNS: same as above (router, 1.1.1.1, 8.8.8.8)
In both setups:
ROCK is fully reachable: I can ping it, open the Web UI (http://rock / http://<ip>), and access \\rock\data from Windows.
The Roon client on Windows finds the ROCK core on the network.
But the update of the core never completes and I eventually get the error:There was an error downloading Roon. Please check your internet connection. {"status":"Failure","exitcode":11}
I also tried setting ROCK to pure DHCP only (no manual static IP on the box, just a DHCP reservation on the router within the correct subnet), and the behaviour is exactly the same.
So the incorrect subnet value in my first post was just a typo in the description, not the real configuration on site. The core is always in the correct subnet; the problem seems to be only with downloading the update itself.
Whilst it doesn’t solve your issue (for which I don’t really have any further suggestions at this time), this configuration will generally cause fewer issues in the future than the use of a static ip address. For example, consider if you change change your router in the future and the new router defaults to a different subnet (for example many ASUS routers default to 192.168.50.0/24). If a device on your network is configured to use a static ip address, then it will become unreacheable with the new router - but with DHCP, as soon as an attempt is made to renew the DHCP lease (or sooner if forced by, for example, a power cycle), the device will get a new ip address within the correct subnet.
OK. Can I suggest, if you are able, that you edit your first post to correct the issue so that no-one else is mislead. You may not have permissions to do this if you have not used the forums a lot.
The only other thing that could possibly relate to your issue (however unlikely) is the possibility of multiple devices with the same ip address.
Have you checked that the static ip address assigned is outside of the ip address pool reserved for DHCP assignment (This may not be so important with DHCP and a DHCP reservation - but is probably still good practise)? If not, you may have a situation where multiple devices are assigned the same ip address which can cause all sorts of issues (although I have to admit that I would have expected some of the other diagnostic steps that you have taken to show symptoms if this were the case)?
Thank you very much for taking the time to explain all this – this is actually my very first post on the forum, so I really appreciate the detailed guidance.
I’ll try to edit my first post to correct the subnet information as you suggested. If my forum permissions don’t allow it yet, at least your clarification in this thread should prevent anyone from being misled.
Regarding IP addressing: yes, I have checked for possible conflicts. The static IP I used for ROCK was always outside the DHCP pool on the router, and with DHCP + reservation I also verified that there are no duplicate addresses on the network.
I understand your point about using DHCP with a reservation being safer in the long run, especially when changing routers or subnets. In my case I tend to prefer a fixed/static address for ROCK because I use IP-based routing / tunnelling rules on my router, but your explanation makes perfect sense and I’ll keep your recommendation in mind for future changes.
Again, thanks for your help and for looking into this, even though it doesn’t directly solve the download/update problem itself.
I’m still hoping that the Roon team might have a chance to look at my case and perhaps provide a direct download link for the core update, so that I could create an image and install it on my NUC manually. It would be ideal for me.
The DHCP reservation will also ensure that the device ip address does not change and thus allow the configuration of routing/tunnelling on the router in exactly the same way as a static ip address.
I don’t think that such a direct download for an up-to-date ROCK image installer exists. The ROCK install guide has always been to install ROCK using the USB boot media and then to immediately perform a ‘reinstall’ from the WebUI in order to bring everything up to date. Consequently the ROCK install images do not get updated very often - as you can see from the fact that the RoonOS version that you have (build 258) was superceded with the release of build 259 in September 2023 but the installer image has still not been updated.
Thanks for reaching out. Can you please use these instructions to upload your ROCK logs to the below link, and let us know once uploaded? You are also free to take a look over the logs yourself, there should be an [updater] trace that specifies the connection attempt and why it failed.
Hello everyone! I’d like to share an update — the issue has been fully resolved.
After a more detailed check, it turned out that the problem wasn’t related to Roon itself.
My network was routed through an Xray-based VPN tunnel, and apparently that type of VPN doesn’t always pass the specific traffic that Roon needs for updates, metadata, and external services.
I switched the network to a stable WireGuard VPN connection directly on my router — and everything started working immediately:
ROCK updated without any errors,
all Roon services are functioning normally again,
Qobuz and metadata load quickly,
the whole system has become noticeably more stable.
So the root cause was the previous VPN setup, not Roon.
Thank you to everyone for the attention and support!
The topic can be closed.
