Snap executable not found, even though it's there


#1

I’ve got a snap that’s being built by build.snapcraft.io for both amd64 and i386. When I install it locally, it works great. When I install it inside of LXD on (amd64) Jenkins, it fails to run the executable, even though it’s there:

+ ls -lath /snap/juju-helpers/7/bin/juju-bundle
-rwxr-xr-x 1 root root 3.7M Jun 13 14:24 /snap/juju-helpers/7/bin/juju-bundle
+ /snap/juju-helpers/7/bin/juju-bundle
/snap/juju-helpers/7/bin/juju-bundle: No such file or directory

I suspect that this is an issue with snap installing the i386 binary, based on https://askubuntu.com/q/133389. This raises two questions:

Is there a way to check which architecture snap you actually have installed? snap info foo doesn’t seem to list it.

How can I tell snap to install a particular arch? I don’t see anything relevant in snap install --help.


#2

It may be confusing but the ENOENT error code is also reported when the dynamic interpreter is not found. Perhaps it is that? Can you look at readelf -e /path/to/executable and see what the lines that say:

  INTERP         0x00000000000002a8 0x00000000000002a8 0x00000000000002a8
                 0x000000000000001c 0x000000000000001c  R      0x1
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]

#3

@zyga: Thanks for the response. This is what readelf gave me:

[Requesting program interpreter: /lib/ld-linux.so.2] 

And then:

+ ls -lath '/lib/ld-linux*'
ls: cannot access '/lib/ld-linux*': No such file or directory

The ldd output is interesting. On my laptop, it shows a number of i386 libraries, but on Jenkins it shows not a dynamic executable.

On a related note, I’ve specified several different architectures in my snapcraft.yml, but it looks like only one is getting built (i386 if all arches are specified, amd64 if i386 is removed). Is that intentional on the part of build.snapcraft.io?

https://build.snapcraft.io/user/knkski/rust-libjuju


#4

ldd is a script, it doesn’t really do good error checking. It just meant it didn’t work correctly. Use readelf -d to see which libraries you really link to. Those can recursively link to more libraries and can even dynamically link to libraries via dlopen. For understanding dlopen it is good to use ltrace (outside of the confinement), e.g. with ltrace -e dlopen+dlmopen+dlclose+dlsym+dlinfo+dlerror /path/to/binary.


#5

@zyga: Good to know about ldd, thanks. FYI, after removing i386 from the list of supported arches and pushing up a new snap, everything started working.


#6

That is probably a configuration switch on some page. I honestly don’t know. CC @sergiusens for help.