[SOLVED] - Port 5.0.1: No such file or directory - but the files are right there!!!

[cad]

Is anyone else experiencing this with v.5.01? I just started using v5.01 x86_64 XFCE and in many different cases I have been getting this error message. For instance:

"env: ‘/usr/lib64/firefox-118.0/firefox’: No such file or directory" - which in this particular case is happening with the Porteus firefox module downloaded from one of the Porteus mirrors.

Even if I get into the /usr/lib64/firefox-118.0/ directory and enter './firefox' - the same thing happens. It has happened with other files as well, in different circumstances (still within 5.01 x86_64 XFCE). This is the very first time I experience something like this. Could it have something to do with the fact that AUFS was compiled with "detect direct branches access (bypassing AUFS)" (I just checked the kernel .config file). I read somewhere that it can in fact affect optimal AUFS performance in strange ways. Though, I am not sure what could cause it. Any thoughts???

[Rava]

Can you post the output of this command of the affected files:

Code: Select all

/bin/ls -ld FILENAME

Use /bin/ls to be sure no alias or function is used (and these could use options that interfere with the operation) but only the ls binary itself.

Any thoughts???

So far, none, sorry.

[cad]

Can you post the output of this command of the affected files:

Code: Select all

/bin/ls -ld FILENAME

Use /bin/ls to be sure no alias or function is used (and these could use options that interfere with the operation) but only the ls binary itself.

Code: Select all

guest@porteus:~$ /bin/ls -ld /usr/lib64/firefox-118.0/firefox
-rwxr-xr-x 1 root root 13652 Sep 27 17:59 /usr/lib64/firefox-118.0/firefox

However,

Code: Select all

guest@porteus:~$ /usr/lib64/firefox-118.0/firefox
bash: /usr/lib64/firefox-118.0/firefox: No such file or directory

Code: Select all

guest@porteus:~$ firefox
env: ‘/usr/lib64/firefox-118.0/firefox’: No such file or directory

and

Code: Select all

guest@porteus:~$ cd /usr/lib64/firefox-118.0/
guest@porteus:/usr/lib64/firefox-118.0$ ls
Throbber-small.gif  application.ini    browser/
crashreporter*      crashreporter.ini  defaults/
dependentlibs.list  firefox*           firefox-bin*
firefox-bin.sig     firefox.sig        fonts/
glxtest*            gmp-clearkey/      icons/
libfreeblpriv3.so*  libgkcodecs.so*    libipcclientcerts.so*
liblgpllibs.so*     libmozavcodec.so*  libmozavutil.so*
libmozgtk.so*       libmozsandbox.so*  libmozsqlite3.so*
libmozwayland.so*   libnspr4.so*       libnss3.so*
libnssckbi.so*      libnssutil3.so*    libplc4.so*
libplds4.so*        libsmime3.so*      libsoftokn3.so*
libssl3.so*         libxul.so*         libxul.so.sig
minidump-analyzer*  omni.ja            pingsender*
platform.ini        plugin-container*  plugin-container.sig
precomplete         removed-files      update-settings.ini
updater*            updater.ini        vaapitest*

So, after you cd into that directory, even a bare 'ls' shows that the file firefox is in there...

Also, when clicking on the firefox icon in the XWindows desktop, this action produces no visible result, as if the file firefox were not present in that directory.

It's a bit puzzling, isn't it? I would really love to find out why and how this is occurring. Thanks for your help...

[itrukrakso]

HI,
One possibility would be 32bit in a 64bit system, or vice versa.
try it:

Code: Select all

 file /usr/bin/firefox && file -L /usr/bin/firefox  

[Rava]

One possibility would be 32bit in a 64bit system, or vice versa.

Indeed, itrukrakso 's "file" command might help - when /usr/bin/firefox is a binary. When it's a script that executes a binary somewhere from inside its scripting the output is not that helpful.

Example:

Code: Select all

root@rava:/usr/local/bin# uname -m
x86_64

x86-64 means I have a 64 bit system. When it would have said i686 (sometimes also i586 or i486 on very old systems) I would have a 32 bit system.

Code: Select all

root@rava:/usr/local/bin# file num
num: symbolic link to num_x86-64

File is a symlink… and by the name of the symlink target one might presume that it's a x86-64 binary, but better be sure:

Code: Select all

root@rava:/usr/local/bin# file num_x86-64 
num_x86-64: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, not stripped

As you can see, my very own written by myself (with essential aid of a dear friend, cause I suck at coding in C) and compiled binary is indeed a 64 bit binary.

HTH.

[beny]

hi cad,upgraded with the firefox 118.0.1 work ok,make a backup of your mozilla directory in guest cache and rerun the firefox bin,also look if in /mnt/memory/images you have the package loaded well, try if work

[cad]

@beny
You were correct. Removed the firefox 118.0 module and replaced it with the 118.0.1 one - the problem is gone and it is all good now. It is possible the removed module was causing the problem by introducing, as itrukrakso suggested, some 32bit in a 64bit system. But if that were the case, I would not be the only one experiencing that problem. If you or anyone else has had this problem with the old firefox 118.0 module, I would like to know. Another possibility could be that I might have mistakenly built an xzm module (not the firefox one) in an ext2 filesystem and perhaps was using it in Porteus' AUFS ext4 filesystem, but at this point I can't tell for sure. Also, before the problem was resolved, I had just updated (yesterday) the Por 5.01 002-xorg module to address the security issue with libvpx and webm related codecs reported by ncmprhnsbl on Oct 3, and do not know if that could have as well played a part...

Thank you all for your help - problem has been fixed!

[beny]

hi cad, if you can use the porteus tool to upgrade the web browser you don't have to do nothing but change the location of the package in/tmp,you have to change in modules and activate,and if you have a lot of data from firefox that you can save like module.xzm there are a lot of thread into the forum,remember when you have the changes activated the behavoir change also.

[cad]

Hi beny, maybe I'm too much "old school" (I like the hands-on approach, which is why I prefer slackware over all other linux distros), but I have never used the porteus tool to upgrade any of the porteus software in my installs - always done it by downloading manually. The old firefox 118.0 module was downloaded and manually placed in the /mnt/live/memory/copy2ram directory and activated there (as an initial trial), and so was the new firefox 118.0.1 module, with identical procedures. In both instances there were no mozilla directories in /home/guest and /home/guest/.cache, with both firefoxes being totally pristine installs. The installation/activation method was identical for both the old and new firefox modules. But there were (and there may have been) other elements at play, as I described in my previous post, which perhaps may have affected the outcome.

[Rava]

@cad Have you tested if the non-working module is of the wrong architecture?
You can access the binary via mloop, then move to /mnt/loop and look where the binary is and do a

Code: Select all

file binary

and compare it to your arch that you get via

Code: Select all

uname -m

If both are not the same, specially when your new working module is the same binary arch as is your system, then this was the issue.

Code: Select all

guest@rava:/usr/local/bin$ file num*
num:        symbolic link to num_x86-64
num_i586:   ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, with debug_info, not stripped
num_x86-64: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, not stripped
guest@rava:/usr/local/bin$ num_i586
bash: /usr/local/bin/num_i586: No such file or directory

As you can see, out of convenience I have the num_i586 and num_x86-64 in all my Linux distros, and I create the "num" symlink towards the correct binary, in this x86-64 system num links to num_x86-64.

On my mono core Porteus 4.0 i586 system on the other hand, num links to num_i586. Because all and any mono-core systems are 32 bit only.


By doing so num works on all my systems, be they x86-64 or i586/i686. And I can copy the binaries from any of my systems to a new system and have the correct binary with me, architecture-wise. I just have to create the appropriate symlink.

[cad]

@Rava
Thank you for your post. I did not check at the time and, unfortunately, the porteus firefox 118.0 module which I downloaded from the vim mirror has been deleted from my system. I would *really* like to test as you suggested, but that original module is no longer available at the vim and other mirrors, having been replaced with the 118.0.1 one. However, for that old module to be not fully compatible with an x86_64 system (which is what I had tested it on), the only possibility would be that it was messed with at the vim server after being uploaded there, don't you think? If you are absolutely certain that there were no architecture incompatibilities with the 118.0 module that you porteus developers uploaded to that mirror, then that would be the only possibility for that old module not to have been compatible with my x86_64 system. I am very certain the firefox module I had downloaded from the vim server was meant for the x86_64 architecture - I was able to activate it in porteus 501 (XFCE) x86_64. I do not really know what to think at this point or how it could be possible to figure out this dilemma now that the old 118.0 module is gone.

[Rava]

I am very certain the firefox module I had downloaded from the vim server was for the x86_64 architecture - I was able to activate it in porteus 501 (XFCE) x86_64.

You can activate any module, regardless of architecture.

But now you (and all lurkers) know how to test if the binary is incompatible for your arch or not. If such thing occurs again in the future. So all is well.

[cad]

Oh, I did not know that... I'll definitely save this thread in my personal folder and tag it for future reference and, if this should happen again, I will test as you suggested before posting here. I do not know if all lurkers will know how to test for architecture compatibility by getting the method you posted here - that would imply that all lurkers will get to read this thread first, which is highly unlikely...

EDIT: Thank you for your work, patience and willingness to be helpful, Rava. I totally appreciate you and the rest of the Porteus Team - you guys are great!