APPRUN_ERROR: No such file or directory

[carlonluca]

I'm having a problem very similar to #148; when running the appimage I get:

APPRUN_ERROR: No such file or directory

The problem only appears on arm64, the x64 appimage works properly. As said in #148, I mounted the appimage and this is what I see in the env file:

APPDIR_EXEC_PATH=$APPDIR/usr/bin/procweb-qt

and in fact it is there:

file usr/bin/procweb-qt
usr/bin/procweb-qt: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (GNU/Linux), dynamically linked, interpreter lib/ld-linux-aarch64.so.1, BuildID[sha1]=5570c8568939fa5570ecf5ede3982e7b88d28867, for GNU/Linux 3.7.0, not stripped

Is the relative path for the interpreter correct? Can this be caused by a missing dependency?

This is the first time I use appimage-builder, so I do not fully understand how it works yet. My project is however open source, so this is the recipe I built: https://github.com/carlonluca/procweb/blob/master/appimage-builder/AppImageBuilder_aarch64.yml.

Any idea how I could debug further? Thanks!

[goldstar611]

I noticed in your x64 yml you have deb [arch=amd64] http:// in the source lines. If you change
deb http://
to
deb [arch=arm64] http://

does that help? I wonder if non-arm64 binaries are inside the appimage.

[goldstar611]

I had a quick moment to run the AppImageBuilder tool against your yml file (but not enough time to compile your project). Assuming your project is compiled correctly, I can see one large issue with the architecture of AppRun, which appears to be x86_64:

~/Desktop/UntitledFolder/AppDir $ find . -type f -executable -exec file {} \;

...
./AppRun: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.32, BuildID[sha1]=b33b58c29edac92944e344dc47324f896ae2f3fe, not stripped

[carlonluca]

Hello,
if I mount my appimage I get:

/tmp/.mount_procwe7C6j7n $ file AppRun
AppRun: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, BuildID[sha1]=db3c30272ec045e00c179e753dda3fb03ad699f7, not stripped

by running the same command you used I can only see aarch64 libraries. I can make it explicit to use arm64 repos, but libs installed from the repos seem to be for the aarch64 arch.

[goldstar611]

How about if you use the strace program to see which file is attempting to be accessed that produces the ENOENT (not found) error. This would be my next step.

[carlonluca]

Unfortunately I did that but I did not get much more info:

chdir("/tmp/.mount_procwengdYOC/runtime/compat") = 0
execve("/tmp/.mount_procwengdYOC/usr/bin/procweb-qt", ["/tmp/.mount_procwengdYOC/usr/bin"...], 0x394e2af0 /* 71 vars */) = -1 ENOENT (No such file or directory)
write(2, "APPRUN_ERROR: No such file or di"..., 39APPRUN_ERROR: No such file or directory) = 39
exit_group(1)                           = ?
+++ exited with 1 +++

[carlonluca]

It is probably something done to the binary by appimage-builder itself. When I copy the binary into the AppDir directory and appimage-builder is executed, the md5 of the binary changes. The new binary stops working and returns the same error of the appimage:

# AppDir/usr/bin/procweb-qt 
bash: AppDir/usr/bin/procweb-qt: No such file or directory

The original binary was working instead.

This is what changes in the elf:

70c70
<        0000000000000260  0000000000000010  WA       6     0     8
---
>        0000000000000220  0000000000000010  WA       6     0     8
102c102
<       [Requesting program interpreter: /lib/ld-linux-aarch64.so.1]
---
>       [Requesting program interpreter: lib/ld-linux-aarch64.so.1]
108c108
<                  0x0000000000000260 0x0000000000000260  RW     0x8
---
>                  0x0000000000000220 0x0000000000000220  RW     0x8
455,456c455,456
<      1: 0000000000004480     0 SECTION LOCAL  DEFAULT   11 .init
<      2: 000000000007b000     0 SECTION LOCAL  DEFAULT   24 .data
---
>      1: 0000000000004480     0 SECTION LOCAL  DEFAULT   11 
>      2: 000000000007b000     0 SECTION LOCAL  DEFAULT   24 
623,649c623,649
<      1: 0000000000000238     0 SECTION LOCAL  DEFAULT    1 .interp
<      2: 0000000000000254     0 SECTION LOCAL  DEFAULT    2 .note.gnu.build-id
<      3: 0000000000000278     0 SECTION LOCAL  DEFAULT    3 .note.ABI-tag
<      4: 0000000000000298     0 SECTION LOCAL  DEFAULT    4 .gnu.hash
<      5: 00000000000002b8     0 SECTION LOCAL  DEFAULT    5 .dynsym
<      6: 0000000000001230     0 SECTION LOCAL  DEFAULT    6 .dynstr
<      7: 000000000000280c     0 SECTION LOCAL  DEFAULT    7 .gnu.version
<      8: 0000000000002958     0 SECTION LOCAL  DEFAULT    8 .gnu.version_r
<      9: 0000000000002a88     0 SECTION LOCAL  DEFAULT    9 .rela.dyn
<     10: 0000000000003700     0 SECTION LOCAL  DEFAULT   10 .rela.plt
<     11: 0000000000004480     0 SECTION LOCAL  DEFAULT   11 .init
<     12: 00000000000044a0     0 SECTION LOCAL  DEFAULT   12 .plt
<     13: 0000000000004dc0     0 SECTION LOCAL  DEFAULT   13 .text
<     14: 000000000000b350     0 SECTION LOCAL  DEFAULT   14 .fini
<     15: 000000000000b370     0 SECTION LOCAL  DEFAULT   15 .rodata
<     16: 0000000000068b14     0 SECTION LOCAL  DEFAULT   16 .eh_frame_hdr
<     17: 0000000000068dc8     0 SECTION LOCAL  DEFAULT   17 .eh_frame
<     18: 0000000000069cac     0 SECTION LOCAL  DEFAULT   18 .gcc_except_table
<     19: 000000000007a4a0     0 SECTION LOCAL  DEFAULT   19 .init_array
<     20: 000000000007a4b8     0 SECTION LOCAL  DEFAULT   20 .fini_array
<     21: 000000000007a4c0     0 SECTION LOCAL  DEFAULT   21 .data.rel.ro
<     22: 000000000007a848     0 SECTION LOCAL  DEFAULT   22 .dynamic
<     23: 000000000007aaa8     0 SECTION LOCAL  DEFAULT   23 .got
<     24: 000000000007b000     0 SECTION LOCAL  DEFAULT   24 .data
<     25: 000000000007b1d8     0 SECTION LOCAL  DEFAULT   25 .qtversion
<     26: 000000000007b1e8     0 SECTION LOCAL  DEFAULT   26 .bss
<     27: 0000000000000000     0 SECTION LOCAL  DEFAULT   27 .comment
---
>      1: 0000000000000238     0 SECTION LOCAL  DEFAULT    1 
>      2: 0000000000000254     0 SECTION LOCAL  DEFAULT    2 
>      3: 0000000000000278     0 SECTION LOCAL  DEFAULT    3 
>      4: 0000000000000298     0 SECTION LOCAL  DEFAULT    4 
>      5: 00000000000002b8     0 SECTION LOCAL  DEFAULT    5 
>      6: 0000000000001230     0 SECTION LOCAL  DEFAULT    6 
>      7: 000000000000280c     0 SECTION LOCAL  DEFAULT    7 
>      8: 0000000000002958     0 SECTION LOCAL  DEFAULT    8 
>      9: 0000000000002a88     0 SECTION LOCAL  DEFAULT    9 
>     10: 0000000000003700     0 SECTION LOCAL  DEFAULT   10 
>     11: 0000000000004480     0 SECTION LOCAL  DEFAULT   11 
>     12: 00000000000044a0     0 SECTION LOCAL  DEFAULT   12 
>     13: 0000000000004dc0     0 SECTION LOCAL  DEFAULT   13 
>     14: 000000000000b350     0 SECTION LOCAL  DEFAULT   14 
>     15: 000000000000b370     0 SECTION LOCAL  DEFAULT   15 
>     16: 0000000000068b14     0 SECTION LOCAL  DEFAULT   16 
>     17: 0000000000068dc8     0 SECTION LOCAL  DEFAULT   17 
>     18: 0000000000069cac     0 SECTION LOCAL  DEFAULT   18 
>     19: 000000000007a4a0     0 SECTION LOCAL  DEFAULT   19 
>     20: 000000000007a4b8     0 SECTION LOCAL  DEFAULT   20 
>     21: 000000000007a4c0     0 SECTION LOCAL  DEFAULT   21 
>     22: 000000000007a848     0 SECTION LOCAL  DEFAULT   22 
>     23: 000000000007aaa8     0 SECTION LOCAL  DEFAULT   23 
>     24: 000000000007b000     0 SECTION LOCAL  DEFAULT   24 
>     25: 000000000007b1d8     0 SECTION LOCAL  DEFAULT   25 
>     26: 000000000007b1e8     0 SECTION LOCAL  DEFAULT   26 
>     27: 0000000000000000     0 SECTION LOCAL  DEFAULT   27

init, data and other sections are lost it seems. Is this expected?

[JohnXLivingston]

As mentionned by @carlonluca , it seems to be the same issue than #278
In #278 , the problem occurs using an official documented config file (bash AppImage), by just replacing the repository: amd64 => aarch64.

[goldstar611]

<       [Requesting program interpreter: /lib/ld-linux-aarch64.so.1]
                                         ^
---
>       [Requesting program interpreter: lib/ld-linux-aarch64.so.1]
                                         ^

I wonder if this is an "off by one" error or intentional. I can understand the reasoning for using a relative path to ld-linux but it seems suspicious to me.

Does the resulting AppDir have a lib/ld-linux-aarch64.so.1 file in it?

[carlonluca]

Yes, I noticed that, but I suspect that is expected. This is inside the AppDir:

./AppDir/lib/aarch64-linux-gnu/ld-linux-aarch64.so.1
./AppDir/lib/ld-linux-aarch64.so.1
./AppDir/runtime/default/lib/ld-linux-aarch64.so.1

and also it seems on x64 the change is identical:

<       [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
---
>       [Requesting program interpreter: lib64/ld-linux-x86-64.so.2]

Missing init and data section is also suspect.

[goldstar611]

Are the sections actually missing or did the names get stripped? I'm not familiar with either ELF format basics or stripping of ELF files.

[carlonluca]

Unfortunately I do not have an answer to this. I guess the names are stripped, not sure if this is a problem or not. However, the fact that the binary cannot be even started seems to suggest there is a problem very early in the process.