Php-fpm: CPU ISA level is lower than required

1

Hi all.

I’m having an installation issue on 1 of 2 servers while trying to add postfix mail.

2 servers with identical hardware, both running Alma 10.2 v2.
When I get to adding php-fpm, one installs just fine where as the other throws the error: “/usr/sbin/php-fpm: CPU ISA level is lower than required”

Any thoughts as to what might be out of whack or what I may have done wrong on the failing server?

Thanks

Glen

2

ISA is “Instruction set architecture” (x86-64-v2 x86-64-v3 x86-64-v4), so if it works on one but not the other, they are probably might not be the same hardware.

You can check what is supported on each system by running:
/usr/lib/ld-linux-x86-64.so.2 --help
If the file is not in /usr/lib, you can search for it with:
sudo find / -mount -type f -iname 'ld-linux-x86-64.so.2'

Longshot: have you updated the uefi on the machines?

3

Thanks for helping.

I have a 3rd local server with same hardware, the 2 mentioned in the original post are remote servers. This local server does not produce the error.

Since I can access the bios on the local server, whether uefi is enabled or disabled, the error does not occur.

I have run : /usr/lib64/ld-linux-x86-64.so.2 –help

When I run : /usr/lib64/ld-linux-x86-64.so.2 –list, it returns: /usr/lib64/ld-linux-x86-64.so.2: missing program name

I don’t know what to add for the pogram name?

Thanks for helping.

4

–help tells you…

Usage: /usr/lib/ld-linux-x86-64.so.2 [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...]

But that is beside the point, you don’t need the --list option.
The command /usr/lib64/ld-linux-x86-64.so.2 –help will show available architectures at the bottom.

For example on my system:

$ /usr/lib/ld-linux-x86-64.so.2 –help
Usage: /usr/lib/ld-linux-x86-64.so.2 [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...]
You have invoked 'ld.so', the program interpreter for dynamically-linked
ELF programs.  Usually, the program interpreter is invoked automatically
when a dynamically-linked executable is started.

You may invoke the program interpreter program directly from the command
line to load and run an ELF executable file; this is like executing that
file itself, but always uses the program interpreter you invoked,
instead of the program interpreter specified in the executable file you
run.  Invoking the program interpreter directly provides access to
additional diagnostics, and changing the dynamic linker behavior without
setting environment variables (which would be inherited by subprocesses).

  --list                list all dependencies and how they are resolved
  --verify              verify that given object really is a dynamically linked
                        object we can handle
  --inhibit-cache       Do not use /etc/ld.so.cache
  --library-path PATH   use given PATH instead of content of the environment
                        variable LD_LIBRARY_PATH
  --glibc-hwcaps-prepend LIST
                        search glibc-hwcaps subdirectories in LIST
  --glibc-hwcaps-mask LIST
                        only search built-in subdirectories if in LIST
  --inhibit-rpath LIST  ignore RUNPATH and RPATH information in object names
                        in LIST
  --audit LIST          use objects named in LIST as auditors
  --preload LIST        preload objects named in LIST
  --argv0 STRING        set argv[0] to STRING before running
  --list-tunables       list all tunables with minimum and maximum values
  --list-diagnostics    list diagnostics information
  --help                display this help and exit
  --version             output version information and exit

This program interpreter self-identifies as: /usr/lib/ld-linux-x86-64.so.2

Shared library search path:
  (libraries located via /etc/ld.so.cache)
  /usr/lib (system search path)

Subdirectories of glibc-hwcaps directories, in priority order:
  x86-64-v4 (supported, searched)
  x86-64-v3 (supported, searched)
  x86-64-v2 (supported, searched)

So on my system I have v2 v3 & v4.

Compare between the working and non working system to find out if missing architectures is actually the problem (and if they actually are the same hardware)

5

Oh, I was looking for something more in-depth!
Anyway, both servers report exactly the same thing:
This program interpreter self-identifies as: /lib64/ld-linux-x86-64.so.2

Shared library search path:
(libraries located via /etc/ld.so.cache)
/lib64 (system search path)
/usr/lib64 (system search path)

Subdirectories of glibc-hwcaps directories, in priority order:
x86-64-v4
x86-64-v3

6

Then the error of missing architecture might be a red herring.

Sorry, I have no further input as to what might be going wrong here. :frowning:

7

Hi and thanks for your time and assistance.

I discovered yesterday that the failing server had a different version of php.
While php and the php-fpm were the same version, this seems to be the point of failure. (I vaguely remember screwing around with alternate php)

The question is, do I reinstall Alma 10.2 v2 and continue or will a future upgrade bite me. Or start over with Alma 9.

8

hi

Could you please run the following command and share the output?

rpm -qf /usr/sbin/php-fpm

thanks