Libraries not found (Ubuntu 24.04 Server arm)

[sccfit]

Hi all... just tried to install nut on fresh install Ubuntu 24 LTS on raspberry pi, installed fine but running sudo nut-scanner -C results in following:

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 XML library (libneon.so) : file not found. XML search disabled.
Cannot load AVAHI library (libavahi-client.so) : file not found. AVAHI search disabled.
Cannot load IPMI library (libfreeipmi.so) : file not found. IPMI search disabled.
Cannot load NUT library (libupsclient.so) : file not found. NUT search disabled.

I switched to Ubuntu because the package in it is closer to current than RPI OS, and I need the tools to connect to identical UPS on one device. I've confirmed libusb-1.0 is installed, but for some reason nut can't find it, do I need to create extra symlinks or something like that?

[jimklimov]

Please retry with higher debug verbosity, e.g.:

:; sudo nut-scanner -DDDDDD -C > /tmp/nutscan.log 2>&1

There would be a huge wall of text about directories it looks into and file names it sees and tries to match there.

I wonder if your system delivers e.g. libusb-1.0.so.1.27.0 and no symlink like libusb-1.0.so which could be in another package.

For context: most of NUT deliverables can be split into packages based on dependencies (e.g. snmp, ipmi, usb etc. drivers) or purpose (client, cgi, ...) However the nut-scanner tool can optionally talk all protocols it can discover, and with usual shared object linking approach it would require all those libraries installed - even if the particular user never needs them (only got USB and has no care and footprint to spare for SNMP or IPMI libs). Instead, shared objects (libraries) are loaded dynamically by the program itself at its discretion - or skipped if the load failed, such as in this case. Why specifically it failed is the root cause to discover here.

[jimklimov]

Also, just in case: how did you install NUT (packages? custom build?) and which version?

[danmrossi]

Must be the OS that NUT was compiled on, I’ve just compiled and installed on Ubuntu 24.04 no issues.

[sccfit]

Sorry, have been on holidays, looping back to this now. I'm not great with Linux/packages/github, I installed using apt which I believe should be version 2.8.1-3.1ubuntu2.

Have run with higher debug verbosity, the following seem to be the most pertinent lines:

   0.001188     [D1]    Built-in:       /usr/lib/gcc/aarch64-unknown-linux-gnu
   0.001239     [D2] Looking for lib libusb-1.0.so in directory #0 : /usr/lib/aarch64-linux-gnu

   -- snip --
   
   0.012290     [D5] Comparing lib libusb-1.0.so with dirpath entry libusb-1.0.so.0
   0.012298     [D5] Comparing lib libusb-1.0.so with dirpath entry libusb-1.0.so.0.4.0

   -- snip --
   
   0.014574     [D1] Looking for lib libusb-1.0.so, found NULL
   
   -- snip --
   0.026829     [D1] nutscan_init: get_libname() did not resolve libname for LibUSB, trying to load it with libtool default resolver
   Cannot load USB library (libusb-1.0.so) : file not found. USB search disabled.

Am I right in thinking that creating a symlink 'libusb-1.0.so' that points to 'libusb-1.0.so.0' in the same directory should resolve the issue in this case?

[jimklimov]

Yes, I wonder why one was not created in the first place (maybe devel packages deliver such a link, or some distro conventions had changed?) :\

At least, not directly a NUT problem, or not sure quickly how to address such distro specifics in common codebase, short of adding a nut-scanner config file/options about such paths.

[jimklimov]

Hm, yeah, the name without trailing numbers seems to come from development packages:

:; grep libusb-1.0.so /var/lib/dpkg/info/*.list
/var/lib/dpkg/info/libusb-1.0-0-dev:amd64.list:/usr/lib/x86_64-linux-gnu/libusb-1.0.so
/var/lib/dpkg/info/libusb-1.0-0:amd64.list:/usr/lib/x86_64-linux-gnu/libusb-1.0.so.0.3.0
/var/lib/dpkg/info/libusb-1.0-0:amd64.list:/usr/lib/x86_64-linux-gnu/libusb-1.0.so.0

Wondering how nobody stumbled on that before. Did everyone have a larger system footprint installed (e.g. did other packagings of NUT depend on *-dev packages of other stuff)?..

At least, this does seem like something NUT codebase can address - beside the idea above for direct run-time modifiable configuration of file names/paths to use, it may be possible to add the name(s) of the library seen at configuration/build time (e.g. libusb-1.0.so.0 or resolved through all the symlinks to "real file" at libusb-1.0.so.0.3.0) to the built-in search list.

I would be wary of just allowing random suffixes to be accepted in the search method; to that end, get_libname_in_dir() explicitly has checks to avoid "*.dll.a", ".so.1.2.3" etc. and only pick the specified file name exactly (notably, not all such names can even be shared objects that we would be able to dynamically load). Although that is still a clumsy option... "If we found nothing exactly, try again with random suffixes allowed and check by dlload()" but that IMHO is an attack waiting to happen :)

[jimklimov]

A practical search on a test system does use realpath() (where available) and practically use the ultimate file name when it looks at a symlink (which does exist):

   0.002097     [D5] Comparing lib libusb-1.0.so with dirpath entry libusb-1.0.so
   0.002108     [D2] Candidate path for lib libusb-1.0.so is /usr/lib/x86_64-linux-gnu/libusb-1.0.so (realpath /usr/lib/x86_64-linux-gnu/libusb-1.0.so.0.3.0)
   0.002119     [D1] Looking for lib libusb-1.0.so, found /usr/lib/x86_64-linux-gnu/libusb-1.0.so.0.3.0
   0.002121     [D1] nutscan_init: get_libname() resolved '/usr/lib/x86_64-linux-gnu/libusb-1.0.so.0.3.0' for LibUSB, loading it
   0.002324     [D1] nutscan_init: succeeded to load the library for LibUSB

Looking at code, I see that for each library of interest, nut-scanner tries one or more patterns via get_libname() and if any of those fails to find an exact filename match in searched directories, it falls back to the likes of nutscan_load_usb_library() (half a dozen of those for different libs) which would try to lt_dlopen() the specified pattern(s) in hopes that the OS resolver would take care of locating the library in some location unexpected by NUT (and maybe under a slightly different name - up to the OS not NUT at this point). This is the part seen in your log too, as:

   0.026829     [D1] nutscan_init: get_libname() did not resolve libname for LibUSB, trying to load it with libtool default resolver

[jimklimov]

Running some experiments with another lib that is easier to fiddle with (NUT only built in this system, not installed into common paths, so its own libupsclient is not resolved via OS paths):

:; ./tools/nut-scanner/nut-scanner -O
Cannot load NUT library (libupsclient.so) : file not found. NUT search disabled.

With the local build in the library path, it is seen:

:; LD_LIBRARY_PATH="`pwd`/clients/.libs:$LD_LIBRARY_PATH" ./tools/nut-scanner/nut-scanner -O -DDDDDD 2>&1  | grep -B5 -A5 'libupsclient\.so\.'

...
   0.014299     [D5] Comparing lib libupsclient.so with dirpath entry libupsclient.so
   0.014308     [D2] Candidate path for lib libupsclient.so is /home/jim/nut/clients/.libs/libupsclient.so (realpath /home/jim/nut/clients/.libs/libupsclient.so.6.0.1)
   0.014312     [D2] Looking for lib libupsclient.so, found in LD_LIBRARY_PATH
   0.014313     [D1] Looking for lib libupsclient.so, found /home/jim/nut/clients/.libs/libupsclient.so.6.0.1
   0.014313     [D1] nutscan_init: get_libname() resolved '/home/jim/nut/clients/.libs/libupsclient.so.6.0.1' for NUT Client library, loading it
   0.014361     [D1] nutscan_init: succeeded to load the library for NUT Client library
...

Removing the .so symlink out of the way:

:; ls -la clients/.libs/libupsclient.so*
lrwxrwxrwx 1 jim jim     21 May 15 17:35 clients/.libs/libupsclient.so -> libupsclient.so.6.0.1
lrwxrwxrwx 1 jim jim     21 May 15 17:35 clients/.libs/libupsclient.so.6 -> libupsclient.so.6.0.1
-rwxr-xr-x 1 jim jim 223376 May 15 17:35 clients/.libs/libupsclient.so.6.0.1

:; mv clients/.libs/libupsclient.so{,.x}

:; LD_LIBRARY_PATH="`pwd`/clients/.libs:$LD_LIBRARY_PATH" ./tools/nut-scanner/nut-scanner -O -DDDDDD 2>&1  | grep -B5 -A5 'libupsclient\.so\.'

...
   0.013544     [D2] Looking for lib libupsclient.so in directory #1 : /home/jim/nut/clients/.libs
   0.013569     [D5] Comparing lib libupsclient.so with dirpath entry libnutclient.so.2.0.2
   0.013586     [D5] Comparing lib libupsclient.so with dirpath entry libupsclient.a
   0.013588     [D5] Comparing lib libupsclient.so with dirpath entry upslog
   0.013589     [D5] Comparing lib libupsclient.so with dirpath entry libnutclientstub.la
   0.013590     [D5] Comparing lib libupsclient.so with dirpath entry libupsclient.so.6.0.1
   0.013591     [D5] Comparing lib libupsclient.so with dirpath entry libupsclient.exp
...
   0.013598     [D5] Comparing lib libupsclient.so with dirpath entry libupsclient.so.x
   0.013599     [D5] Comparing lib libupsclient.so with dirpath entry libnutclient.a
   0.013600     [D5] Comparing lib libupsclient.so with dirpath entry libnutclientstub.a
   0.013600     [D5] Comparing lib libupsclient.so with dirpath entry upsset.cgi
   0.013601     [D5] Comparing lib libupsclient.so with dirpath entry libupsclient.so.6
...
   0.013613     [D1] Got no strong candidate path for lib libupsclient.so in /home/jim/nut/clients/.libs, but saw seemingly related names (are you missing a symbolic link, perhaps?) e.g.: libupsclient.so.6.0.1
   0.013619     [D2] Looking for lib libupsclient.so in directory #2 : /usr/lib/x86_64-linux-gnu
...

So it even recognizes that file, just not as a "strong" candidate.

[jimklimov]

As a side note, this may also be a concern for DMF effort (currently awaiting its destiny in another branch):

• https://app.circleci.com/pipelines/github/jimklimov/nut/1663/workflows/39cda40a-9cdd-437f-bc47-8ac693f290e0/jobs/4951 after PR FTY remerge from master as of 2024-03-02 #2275 for issue track Upstreaming improvements from 42ity/nut fork #1316

...
Error loading Neon library required for DMF: libneon.so not found by dynamic loader; please verify it is in your /usr/lib or some otherwise searched dynamic-library path, under this exact name (maybe you just need a symlink?)
Error loading Neon library required for DMF: libneon-gnutls.so not found by dynamic loader; please verify it is in your /usr/lib or some otherwise searched dynamic-library path, under this exact name (maybe you just need a symlink?)
=== DMF-Test: Error parsing data: -1