Dennis HilkLinux Fix LabDE

NixOS & Configuration

A generic Linux binary cannot find its loader on NixOS

An existing executable fails before normal startup because it expects an FHS loader or libraries. Inspect ELF metadata and choose a scoped packaging route.

Editorial source review: Start with the evidenceShare this guide
On this page
  1. Symptoms & scope
  2. Possible causes
  3. Diagnose safely
  4. Evidence-guided next steps
  5. References & review
  6. Related problems

Symptoms & scope

  • An existing executable reports a missing interpreter or the NixOS stub-loader message.
  • Libraries installed in systemPackages do not automatically satisfy its generic library search path.

Relevant environment

NixOS running externally distributed dynamically linked ELF binaries; architecture and ABI must also match.

Recognizable messages (synthetic examples)
Could not start dynamically linked executable: /home/example/vendor/bin/tool

This points to environment assumptions; inspect the ELF interpreter before treating it as an application crash.

Possible causes

These are possible explanations, not a confirmed diagnosis. Several independent faults can coexist.

  • The binary may request a conventional /lib loader absent or replaced by a stub on NixOS.
  • Its runtime library search paths may not include the Nix store; wrong architecture is a separate possible failure.

Diagnose safely

Run one command at a time in the relevant session. Read the explanation first. Uppercase placeholders need your own values; tools and privileges vary by distribution. These commands are displayed here and never executed by the website.

Check 1

Replace the path with the binary; readelf from binutils inspects it without executing it.

readelf -l /path/to/program

Interpret the result: The INTERP segment names the requested loader. No interpreter segment may mean a static binary or a different file type; confirm its ELF header.

Check 2

Use the same trusted or untrusted file; this metadata read does not run its loader or entry point.

readelf -d /path/to/program

Interpret the result: NEEDED and RPATH/RUNPATH identify dependencies and search assumptions. Installing a package globally does not rewrite these fields.

Evidence-guided next steps

Use or create a Nix-compatible package

If available, use the intended Nixpkgs package. Otherwise package the verified upstream binary with suitable dependencies and autoPatchelfHook, or build from source so its loader and runtime references enter the correct closure.

Precautions: Keep the original binary immutable for comparison and verify licensing and source identity. Do not create random global loader symlinks.

Recovery / rollback: Remove the custom package reference and restore the previous configuration or package version; retain original artifacts.

Did this solution help you?

Share this solution#

Use a scoped compatibility environment

If the program downloads further binaries or resists packaging, use a documented buildFHSEnv wrapper or deliberately enable nix-ld with its required library set. Keep compatibility limited to the intended architecture and workflow.

Precautions: nix-ld is not an architecture emulator or a guarantee of library ABI compatibility. Its libraries belong in its documented setting, not merely environment.systemPackages.

Recovery / rollback: Remove the wrapper or revert nix-ld settings and start a fresh login environment to restore prior variables.

Did this solution help you?

Share this solution#

References & review

This guide was prepared from primary project or distribution sources and reviewed on the date shown. This is an editorial source check, not evidence that a fix was reproduced on your hardware. Diagnostic log examples are synthetic fixtures. Version-dependent details must be checked against your installed release.