Debian without basic commands: 'No such file or directory'

Question

My new VPS is running Debian 5.0 (bash 3.2.29), and some commands seems to be missing. For example the ps command is not here, neither is ls (but dir works). Is there a package missing or what's the deal?

:~# type ps
ps is hashed (/bin/ps)
:~# ps
-bash: /bin/ps: No such file or directory

:~# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

:~# /bin/ps
-bash: /bin/ps: No such file or directory

Edit: More info req from comments:

• It's 64bit
• Don't know any details on the actual installation.
• It's a virtual machine running virtuozzo & plesk
• readelf shows that /bin/ps and /bin/ls are 32bit. And theres no 32bit /lib/ld-linux-so.2. How did that happen? Error in installation or what?

For completion's sake:

# file /bin/ps
/bin/ps: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), 
dynamically linked (uses shared libs), for GNU/Linux 2.0.0, stripped

# file /bin/ls
/bin/ls: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
dynamically linked     (uses shared libs), for GNU/Linux 2.0.0, stripped

# uname -mrvs
Linux 2.6.18-028stab069.6 #1 SMP Wed May 26 18:10:06 MSD 2010 x86_64


# readelf -l /bin/ps

Elf file type is EXEC (Executable file)
Entry point 0x8049040
There are 6 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  PHDR           0x000034 0x08048034 0x08048034 0x000c0 0x000c0 R E 0x4
  INTERP         0x0000f4 0x080480f4 0x080480f4 0x00013 0x00013 R   0x1
      [Requesting program interpreter: /lib/ld-linux.so.2]
  LOAD           0x000000 0x08048000 0x08048000 0x071fa 0x071fa R E 0x1000
  LOAD           0x007200 0x08050200 0x08050200 0x005a0 0x01e5c RW  0x1000
  DYNAMIC        0x0076f8 0x080506f8 0x080506f8 0x000a8 0x000a8 RW  0x4
  NOTE           0x000108 0x08048108 0x08048108 0x00020 0x00020 R   0x4

 Section to Segment mapping:
  Segment Sections...
   00     
   01     .interp 
   02     .interp .note.ABI-tag .hash .dynsym .dynstr 
  .gnu.version .gnu.version_r .rel.got .rel.bss .rel.plt
  .init .plt .text .fini .rodata 
   03     .data .got .dynamic .bss 
   04     .dynamic 
   05     .note.ABI-tag 

Solution

Service provider reinstalled the system. It was definitely something funky about it. The memory consumption dropped from about 750MB to 120MB as well.

Answer 1

When exec* returns -ENOENT, either the binary is missing or the interpreter is missing.

Obviously, /bin/ps exists, otherwise it wouldn't be in hashed in the shell. But the dynamic linker it depends on probably doesn't exist on your system. If GNU binutils installed, you can easily determine if this is the case.

$ readelf -l /bin/ps
…
  INTERP         0x0000000000000270 0x0000000000400270 0x0000000000400270
                 0x000000000000001c 0x000000000000001c  R      1
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
…

/lib64/ld-linux-x86-64.so.2 exists on my Debian Squeeze/Sid hybrid test machine.

One possibility is that you somehow installed 32-bit packages without the necessary 32-bit libraries. For example, if I try to run a 32-bit binary on a 64-bit-only system,

# on another system for 32-bit development
$ echo 'int main(){}' > 32bit.c
$ cc -m32 -o 32bit 32bit.c
# on a 64-bit system without 32-bit libraries
$ ./32bit
-bash: ./32bit: No such file or directory
$ readelf -l 32bit
…
  INTERP         0x000154 0x08048154 0x08048154 0x00013 0x00013 R   0x1
      [Requesting program interpreter: /lib/ld-linux.so.2]
…
$ ls /lib/ld-linux.so.2
ls: cannot access /lib/ld-linux.so.2: No such file or directory

Another possibility is that you are trying to run LSB binaries on a system without LSB base libraries installed, e.g. a scenario like http://stackoverflow.com/questions/1562071, or trying to use Glibc-based packages on a µClibc-only system, or a multitude of other similar situations.

I do have to ask — how was this system installed? None of this will be true by default, somebody had to go muck with things.