Fix: './hlds_linux: No such file or directory' (Missing 32-bit Loader)

./hlds_linux: No such file or directory — on a file that is right there, executable, owned by the right user — is one of the most misleading errors in the whole CS 1.6 stack. The file exists. What is missing is the 32-bit ELF interpreter the kernel needs to load it: /lib/ld-linux.so.2. HLDS is a 32-bit binary from 2003, and a modern 64-bit Debian or Ubuntu install ships none of the 32-bit runtime by default. The kernel cannot find the loader named inside the ELF header, and reports that as "No such file or directory" — about the loader, not about hlds_linux.

1. Prove it is the loader, not the file

Confirm the diagnosis before installing anything. First, the file really is there and is 32-bit:

file hlds_linux

It should say ELF 32-bit LSB executable, Intel 80386. Now ask what interpreter it needs and whether that interpreter resolves:

ldd hlds_linux

If ldd reports not a dynamic executable, or lists the loader as not found, the 32-bit runtime is missing. That is the whole problem.

2. Enable i386 multiarch

On a 64-bit Debian/Ubuntu you must explicitly tell dpkg it is allowed to install 32-bit packages:

sudo dpkg --add-architecture i386
sudo apt update

Without this step, apt cannot even see the :i386 packages you are about to ask for.

3. Install the 32-bit runtime

sudo apt install -y lib32gcc-s1 lib32stdc++6 libc6:i386 libncurses6:i386 libcurl4:i386

libc6:i386 is the package that actually provides /lib/ld-linux.so.2 and the core C library — it is the one that clears this specific error. lib32gcc-s1 and lib32stdc++6 satisfy the GCC/C++ runtime the engine and its libraries need, libncurses6:i386 is for the text console, and libcurl4:i386 covers HTTP-using components. On older releases the GCC package is named lib32gcc1 instead of lib32gcc-s1; if apt cannot find one, try the other. The full dependency list, including what modules pull in later, is in the 32-bit library guide.

On RHEL, CentOS, AlmaLinux or Rocky

The Red Hat family does not use dpkg multiarch; you install the 32-bit .i686 packages directly:

sudo dnf install -y glibc.i686 libstdc++.i686 ncurses-libs.i686 libcurl.i686

glibc.i686 is the equivalent of libc6:i386 — it is the one that provides the 32-bit loader and clears this error. On very old CentOS 7 boxes the command is yum instead of dnf, and the package names are identical.

4. Start the server

cd /home/steam/hlds
./hlds_run -game cstrike -strictportbind -ip 0.0.0.0 -port 27015 \
  +map de_dust2 +maxplayers 20 +sv_lan 0

It should now boot to a map instead of dying instantly. Note the distinction between the two binaries: hlds_run is a 64-bit-friendly shell wrapper that launches and, after a crash, relaunches the real 32-bit engine hlds_linux. The "No such file or directory" error is raised by hlds_linux — which is why running hlds_run can appear to start and then immediately die, with the real error buried in debug.log rather than on your terminal. When in doubt, run ./hlds_linux directly to see the loader error unfiltered.

Common errors

• error while loading shared libraries: libstdc++.so.6: cannot open shared object file — you got past the loader but a 32-bit library is still missing. Install lib32stdc++6. This is the natural next error after fixing the loader, and you fix them one library at a time until ldd is clean.
• ldd still says the loader is not found after installing libc6:i386 — you skipped dpkg --add-architecture i386, so apt installed nothing useful. Add the architecture, apt update, and reinstall.
• The file genuinely is missing — if file hlds_linux reports the file does not exist, this is not the loader problem; App 90 did not download. Re-run app_update 90 validate per the install guide.
• wrong ELF class: ELFCLASS64 on a self-built binary — different problem: you compiled a 64-bit object. See that error.

Verification

Re-run the check that diagnosed it:

ldd hlds_linux

Every line must now resolve to a real path — no not found. Then start the server and confirm it reaches a map and binds the port:

ss -lunp | grep 27015

should show hlds_linux listening. A resolving ldd, a server that boots to de_dust2, and a bound UDP port together confirm the 32-bit runtime is complete. From here, layer on ReHLDS and the rest of the stack.