Ständige locale-Warnungen bei jedem Befehl? Die Sprachumgebung ist gesetzt, aber nicht erzeugt. Ein Generierungslauf beendet das Gemecker dauerhaft.
Aufwand:
ca. 15 Min.
Voraussetzung:
sudo-Rechte, Terminal
Das Symptom
Bei fast jedem Befehl — besonders auf einem frisch aufgesetzten Server oder nach
dem Einloggen per SSH — erscheinen Warnungen wie cannot change locale oder
LC_ALL: cannot change locale (de_DE.UTF-8). Die Befehle funktionieren meist
trotzdem, aber das Gemecker wiederholt sich bei jeder Aktion.
Die „Layer 8“-Wahrheit
Eine Sprachumgebung (Locale) regelt Sprache, Zeichensatz, Datums- und
Zahlenformate. Der Fehler entsteht durch einen simplen Widerspruch: Irgendwo ist
eine bestimmte Umgebung eingestellt, aber sie wurde nie erzeugt. Das System
soll etwas verwenden, das es nicht besitzt — und meldet das bei jeder Gelegenheit.
Besonders häufig ist der SSH-Fall: Der lokale Rechner schickt beim Verbinden seine
eigene Spracheinstellung mit, und der Server kennt sie nicht. Deshalb gibt es zwei
saubere Wege — die passende Umgebung auf dem Server erzeugen, oder dem eigenen
SSH-Client abgewöhnen, die Sprachvariablen überhaupt mitzusenden. Beides beendet
die Warnungen dauerhaft, und beides ist besser, als sie jahrelang zu überlesen.
Die echte, verifizierte Lösung
1000 % faktenbasiert. Jeder Befehl ist real, jeder Pfad existiert. Schritt für Schritt:
1.
Den Widerspruch verstehen
Die Warnung erscheint, weil eine Sprachumgebung eingestellt ist, die auf dem System gar nicht erzeugt wurde. Oft bringt eine SSH-Sitzung die Spracheinstellung des lokalen Rechners mit, die der Server nicht kennt. Zuerst die aktuelle Belegung ansehen:
locale
2.
Die gewünschte Sprachumgebung freischalten
In der Datei /etc/locale.gen die benötigte Zeile — etwa „de_DE.UTF-8 UTF-8“ oder „en_US.UTF-8 UTF-8“ — einkommentieren (die Raute davor entfernen).
3.
Die Sprachumgebungen erzeugen
Danach die freigeschalteten Umgebungen tatsächlich generieren. Erst jetzt existieren sie auf dem System:
sudo locale-gen
4.
Die Standardsprache systemweit festlegen
Die gewünschte Umgebung als Standard setzen, damit jede neue Sitzung sie verwendet:
sudo update-locale LANG=de_DE.UTF-8
5.
Bei SSH: den Client bremsen
Kommt die störende Einstellung per SSH vom eigenen Rechner, kann man dem Client abgewöhnen, die Sprachvariablen mitzuschicken — dann hört die Warnung auch ohne Serveränderung auf. Das ist übrigens keine Eigenart von SSH selbst: Von Haus aus sendet ssh gar keine Umgebungsvariablen, erst das Debian-Paket openssh-client trägt in /etc/ssh/ssh_config die Zeile SendEnv LANG LC_* nach. Alternativ die Umgebung auf dem Server einfach vollständig bereitstellen.
Häufige Fragen (FAQ)
?Warum meckert das System über die Sprachumgebung, funktioniert aber?
Weil die betroffenen Programme auf eine Standardeinstellung zurückfallen. Die Warnung besagt, dass eine angeforderte Sprachumgebung nicht erzeugt wurde – etwa de_DE.UTF-8. Das ist meist folgenlos, kann aber Sortierung, Datumsformate und Zeichenkodierung stillschweigend verändern.
?Die Meldung erscheint nur bei SSH-Verbindungen. Wieso?
Weil der SSH-Client seine eigene Sprachumgebung an den Server durchreicht. Kennt der Server diese nicht, beschwert er sich – obwohl lokal alles stimmt. Entweder erzeugen Sie die Sprachumgebung auf dem Server, oder Sie unterbinden das Durchreichen in der SSH-Konfiguration des Clients.
Belege
Diese Seite ist gegen die folgenden Primärquellen geprüft – Hersteller, Standard oder Gesetzestext. Wer es nicht glaubt, muss es nicht: Da steht, wo es nachzulesen ist.
SSH verweigert den Schlüssel, weil die Rechte zu offen seien? Ein privater Schlüssel darf nur dir gehören — mit einem chmod ist es in Sekunden behoben.
SSH warnt 'REMOTE HOST IDENTIFICATION HAS CHANGED' und 'Host key verification failed'? So prüfst du die Ursache und entfernst den alten Schlüssel sicher.
apt install meldet 'E: Unable to locate package'? Meist fehlt ein apt update, das Repository oder es ist ein Tippfehler. So installierst du das Paket doch.