Dennis HilkLinux Fix LabEN

NixOS und Konfiguration

Ein allgemeines Linux-Programm findet unter NixOS seinen Loader nicht

Eine vorhandene Programmdatei scheitert wegen erwartetem FHS-Loader oder Bibliotheken. Prüfe ELF-Metadaten und wähle einen gezielten Paketweg.

Redaktionelle Quellenprüfung: Mit den Hinweisen beginnenAnleitung teilen
Auf dieser Seite
  1. Symptome und Geltungsbereich
  2. Mögliche Ursachen
  3. Sicher prüfen
  4. Nächste Schritte nach Befund
  5. Quellen und Prüfung
  6. Verwandte Probleme

Symptome und Geltungsbereich

  • Eine vorhandene Programmdatei meldet fehlenden Interpreter oder den NixOS-Stub-Loader.
  • Bibliotheken in systemPackages erfüllen nicht automatisch seinen allgemeinen Suchpfad.

Betroffene Umgebung

NixOS mit extern verteilten dynamisch gelinkten ELF-Programmen; Architektur und ABI müssen ebenfalls passen.

Erkennbare Meldungen (synthetische Beispiele)
Could not start dynamically linked executable: /home/example/vendor/bin/tool

Dies verweist auf Umgebungsannahmen; prüfe den ELF-Interpreter vor der Annahme eines Anwendungsabsturzes.

Mögliche Ursachen

Das sind mögliche Erklärungen, keine bestätigte Diagnose. Mehrere unabhängige Fehler können gleichzeitig vorliegen.

  • Das Programm kann einen üblichen /lib-Loader anfordern, der unter NixOS fehlt oder durch einen Stub ersetzt ist.
  • Seine Bibliothekssuchpfade können den Nix-Store nicht enthalten; eine falsche Architektur ist ein eigener möglicher Fehler.

Sicher prüfen

Führe jeweils einen Befehl in der passenden Sitzung aus. Lies zuerst die Erklärung. Großgeschriebene Platzhalter brauchen deine Werte; Werkzeuge und Rechte unterscheiden sich je nach Distribution. Die Website zeigt Befehle an und führt sie niemals aus.

Prüfschritt 1

Ersetze den Pfad durch das Programm; readelf aus binutils liest es ohne Ausführung.

readelf -l /path/to/program

Ergebnis einordnen: Das INTERP-Segment nennt den angeforderten Loader. Ohne Segment kann die Datei statisch oder ein anderer Dateityp sein; prüfe den ELF-Header.

Prüfschritt 2

Nutze dieselbe Datei auch bei ungeklärter Herkunft; die Metadatenprüfung startet weder Loader noch Programm.

readelf -d /path/to/program

Ergebnis einordnen: NEEDED und RPATH/RUNPATH nennen Abhängigkeiten und Suchannahmen. Globale Paketinstallation schreibt diese Felder nicht um.

Nächste Schritte nach Befund

Ein Nix-kompatibles Paket nutzen oder erstellen

Nutze nach Möglichkeit das vorgesehene Nixpkgs-Paket. Verpacke sonst das geprüfte Upstream-Programm mit passenden Abhängigkeiten und autoPatchelfHook oder baue aus Quellen für korrekte Laufzeitverweise.

Vorsicht: Bewahre das Originalprogramm zum Vergleich unverändert auf und prüfe Lizenz und Quellidentität. Erstelle keine beliebigen globalen Loader-Symlinks.

Wiederherstellung / Rücknahme: Entferne den eigenen Paketverweis und stelle frühere Konfiguration oder Paketversion zurück; behalte Originalartefakte.

Hat dir dieser Hinweis geholfen?

Hinweis teilen#

Eine gezielte Kompatibilitätsumgebung verwenden

Wenn das Programm weitere Binärdateien lädt oder schwer paketierbar ist, nutze einen dokumentierten buildFHSEnv-Wrapper oder bewusst nix-ld mit benötigten Bibliotheken. Begrenze dies auf vorgesehene Architektur und Ablauf.

Vorsicht: nix-ld emuliert keine Architektur und garantiert keine ABI-Kompatibilität. Seine Bibliotheken gehören in die dokumentierte Vorgabe, nicht nur environment.systemPackages.

Wiederherstellung / Rücknahme: Entferne den Wrapper oder stelle nix-ld-Werte zurück und melde dich neu an für die früheren Umgebungsvariablen.

Hat dir dieser Hinweis geholfen?

Hinweis teilen#

Quellen und Prüfung

Diese Anleitung basiert auf Originalquellen von Projekten oder Distributionen und wurde am genannten Datum redaktionell geprüft. Das ist eine Quellenprüfung, kein Nachweis einer auf deiner Hardware reproduzierten Lösung. Log-Beispiele sind synthetische Testdaten. Versionsabhängige Details müssen zur installierten Ausgabe passen.