Confirmed error, and fixed it. ![]()
To ensure you get the updated script:
sherpa reset
… then try your regular commands. ![]()
Confirmed error, and fixed it. ![]()
To ensure you get the updated script:
sherpa reset
… then try your regular commands. ![]()
Everything is back to normal now, and no weird errors are showing up. Thanks ![]()
Great! ![]()
Also suggest installing SortMyQPKGs to ensure your packages start in a working order on bootup:
sherpa install sort
Which leads to my second point: your uptime is a little high. Try letting it get no-higher than about 2 months. I reboot my production NAS every 8 weeks.
After upgrading the NZBHydra2 QPKG from v260501 to v260912, NZBHydra2 9.0.1 no longer starts on my QNAP running QTS 4.3.6, build 20240619. The downloaded amd64-linux release uses the native ./core binary, which requires GLIBC_2.32, GLIBC_2.33 and GLIBC_2.34. These versions are unavailable in this QTS release.
Hi @Tristan and welcome to the new forum. ![]()
Ah, that’s a problem. I may have to set the older QTS versions to use the previous NZBHydra release, as I still don’t know how to package an updated glibc.
An alternative is to run NZBHydra from Java and Python source. This should work on any NAS where Java 17 can be installed. This would take some time todo, so I’ll work on limiting the NZBHydra release on old QTS versions for-now.
Edit: hmm, actually, this will be a problem for all QTS releases (until QTS 6) as they all have old glibc versions. ![]()
@Tristan, the new NZBHydra 2 QPKG (260920) is now available. This will “pin” the installed application version to 8.9.0:
sherpa upgrade new
Note: don’t upgrade the NZBHydra application through the UI, even if it wants you to!
Wow that took you long enough
Thanks for the quick action, and fingers crossed you can find a solution to run it from Java and Python source.
Cheers mate! ![]()
I’m having another shot at figuring-out the glibc thing… so-far today, I’ve had some minor success.
![]()
@Tristan, looks like the NZBHydra devs have released a new version (9.0.6) to support older glibc installations.
I’ve tried it here and it works fine in QTS 5.2.10 on my only x86-64 NAS, but I don’t have an older x86-64 NAS model running QTS 4.3.6 to test it on.
I’ve pushed an updated NZBHydra2 QPKG (260929) to GitHub, and it’s now available to everyone. Can you please upgrade your NZBHydra2 QPKG and let me know if it runs?
sherpa upgrade nzbhydra2
Update: NZBHydra2 9.1.0 has just been released, and also works fine here. ![]()
Nice, works perfect now. NZBHydra2’s database migration from H2 2.1 to 2.4 required approximately five minutes on my machine though. Sherpa’s two-minute startup timeout repeatedly terminated the process before completion. Running NZBHydra2 manually allowed the migration to finish successfully, after which the application started normally.
Ah, good pickup. ![]()
What is your NAS model please?
Also @Tristan, which timeout expired while the database was migrating? Was it the port check?
It should be in the service-script log:
/etc/init.d/nzbhydra2.sh log
My NAS is a TS-879 Pro, running QTS 4.3.6 build 20240619.
Yes, it was the port check. The service log showed:
test for port 5076 response (no-more than 120 seconds): failed
no response on configured port(s)
stop daemon PID ... with SIGTERM
The H2 2.1 to 2.4 database migration ultimately took 303.808 seconds. Sherpa therefore terminated it after 120 seconds on each attempt. I started NZBHydra2 manually to allow the migration to finish, after which the port check completed successfully.
Good work mate. ![]()
I’ll increase the port check timeout to 6 minutes in the next NZBHydra2 QPKG release, which will be quite-soon. It’s too-late to help your installation, but it may help someone else.
Thanks for reporting this. ![]()
I am using FileBrowser Quantum on my Home Assistant setup, and it works really well.
I look forward to the RC to test.
Thank you!
It’s available now. ![]()
Another small problem with Watcher, after a reboot of the NAS I got this:
load ports from configuration file: /share/CACHEDEV1_DATA/.qpkg/OWatcher3/service.lib: line 575: /opt/bin/jq: No such file or directory
/share/CACHEDEV1_DATA/.qpkg/OWatcher3/service.lib: line 576: /opt/bin/jq: No such file or directory
OK
/share/CACHEDEV1_DATA/.qpkg/OWatcher3/service.lib: line 587: /opt/bin/jq: No such file or directory
! no port specified
= source: watcher3.sh, action: start, time: Wed 28 Oct 2026 8:47:16 PM CET, result: FAILED, elapsed: 803ms, load: 1.83
Seems jq is missing and sherpa fix doesn’t install this, what’s the preferred way to install?
Hi mate, Watcher is no-longer supported by sherpa. So, it no-longer fixes Watcher.
But, to get you past the current error message, install the jq IPK manually:
opkg install jq
Ah check, thanks, just too lazy to migrate I guess.
Migration for Watcher was an option for a while, but not anymore. From memory, we progressed to a Python version unsupported by Watcher.