firewire
13 April 2025 17:35
1
# nut-scanner throws the following errors:
Cannot load USB library (libusb-1.0.so) : file not found. USB search disabled.
Cannot load SNMP library (libnetsnmp.so) : file not found. SNMP search disabled.
Cannot load AVAHI library (libavahi-client.so) : file not found. AVAHI search disabled.
Cannot load NUT library (libupsclient.so) : file not found. NUT search disabled.
No start IP, skipping NUT bus (old connect method)
# ls -la /usr/lib/libusb* shows the following symlink:
/usr/lib/libusb-1.0.so.0 -> libusb-1.0.so.0.4.0
/usr/lib/libusb-1.0.so.0.4.0
The workaround by manually creating a symlink from libusb-1.0.so.0.4.0 to libusb-1.0.so results in a working nut-scanner.
So libusb was updated from 1.0.26 to 1.0.27 in August 2024 back in Core Update 188 and this updated the libusb library from 1.0.so.0.3.0 to 1.0.so.0.4.0
It is now clear that nut has a dependency on libusb but it was not shipped after libusb was updated as that dependency was not recognised or know about.
Clearly not many people have been using nut with Core Updates after CU188 as your finding is the first notification of this issue.
New CU installations after CU188 would work fine with nut, it is only updated versions from CU188 or earlier that will have the problem.
When I am back at home I will do a patch submission to ship nut so the library linkage gets updated.
Bug has been raised for this so that it is recorded and not forgotten about.
https://bugzilla.ipfire.org/show_bug.cgi?id=13840
lsd_87
7 August 2026 12:56
3
Not sure but nut-scanner appears to not be working on 2.29 core 203.
Had to do the link fix to get it to sort of working (only interested in the USB bit)
In /usr/lib
ln -s libusb-1.0.so.0.6.0 libusb-1.0.so
ls -la libusb*
Why do you think that. What error messages did you get?
I just installed nut onto a vm CU203 system and then via the console command line I ran the command
nut-scanner -D
and here are the lines extracted from that output related to libusb
0.001083 [D1] Looking for lib libusb-1.0.so.0.6.0, found /usr/lib/libusb-1.0.so.0.6.0
0.001086 [D1] nutscan_init: get_libname() resolved '/usr/lib/libusb-1.0.so.0.6.0' for LibUSB, loading it
0.001400 [D1] nutscan_init: succeeded to load the library for LibUSB
It quite happily found libusb-1.0.so.0.6.0 with my library symlinks being
ls -hal /usr/lib/libusb*
lrwxrwxrwx 1 root root 19 Jul 14 13:53 /usr/lib/libusb-1.0.so.0 -> libusb-1.0.so.0.6.0
-rwxr-xr-x 1 root root 132K Jul 14 16:13 /usr/lib/libusb-1.0.so.0.6.0
So it didn’t need to have the libusb-1.0.so link, so the fix that nut put in place in version 2.8.3 still appears to be working.
Can you remove that symlink that you created and then run the command
nut-scanner -D and show the lines related to libusb
lsd_87
7 August 2026 14:00
5
Without the symlink libusb-1.0.so I put in, running nut-scanner -D gives
nut-scanner -D
Leigh Dodd:
0.001661 [D1] Looking for lib libusb-1.0.so.0.5.0, found (null)
This is the appropriate part and for some reason your nut is trying to find libusb-1.0.so.0.5.0 while libusb-1.0.so.0.6.0 is installed so hence it doesn’t find it.
In another post on nut you mentioned that your version was nut-2.8.4-15 on CU203.
Was your CU203 system an upgrade from CU202 or was it a fresh install?
lsd_87
7 August 2026 14:55
7
Just checked the iso file - ipfire-2.29-core202x86_64-2026-07-17-1134 so 202
I think I have found what the problem is.
Back in 2025, I identified that nut had become dependent on libusb and this had been missed with the libusb update to version 1.0.29
I added a line to the libusb lfs file to flag up that nut was dependent on libusb and had to be re-shipped when libusb was updated.
That line got added but was then reverted as it was believed that a regression in nut had been fixed and so shipping it was no longer required.
Going through some of the issues in nut related to libusb, it looks like nut looks for an explicit version of libusb based on the version when it was built. So if libusb is updated but nut is not re-shipped then nut stays looking for the old libraries.
Making the link to libusb-1.0.so works because nut still has a fallback that if looking for the explicit version, it fails to find it then it will llok for that library but normally that is only provided if you have the development sources for a package, which IPFire and most distros don’t have unless you explicitly install them.
I think if you
Remove the symlink you created between libusb-1.0.so and libusb-1.0.so.0.6.0
uninstall nut
remove the cached version of nut from the directory /opt/pakfire/cache/
install nut again
you should then get the latest built version based on libusb-1.0.30 which should then use the correct library. Let us know if this fixes it for you.
My test vm system was a fresh install of CU203, not an update from CU202 to CU203, so it automatically had the updated version of nut installed.
lsd_87
7 August 2026 16:39
9
Yep that worked - sorry to cause you work
nut-scanner -D
0.033140 [D1] SCANS DONE: free resources: USB
That is good news.
No problem with the work. Good to have it highlighted so it could be fixed.
I will aim to make sure we remember that nut has to be shipped when libusb is updated in the future.
guenni
5 September 2026 12:42
11
Had the same problem. Solution from Adolf worked for me, too (delete symlink and so on).
But additionally I had to create the symlink afterward, otherwise there would be no connection possible (upsc USV says: Error: Driver not connected)
Therefore you need: ln -s /usr/lib/libusb-1.0.so.0.6.0 /usr/lib/libusb-1.0.so.0
(IPFire 2.29 (x86_64) - Core-Update 203)
Not totally sure.