Debian testing: sysvinit-core nur ohne synaptic und lightdm

[Hans-Martin]

Ich werde in den nächsten Tage einen Rechner für Bekannte mit System und Software versehen. Da testing demnächst stable wird, plane ich diese Version und habe heute auf meinem Rechner - standardmäßig nütze ich aktuell stable und habe zusätzlich noch oldstable installiert - als weiteres System zum Testen die Version testing installiert.

Alles lief gut, bis auf das aus der Vergangenheit bekannte Problem, dass trotz der gewählten Hauptkodierung de_DE@ euro, also iso-8859-15, die Umlaute bei Nutzung der Textkonsolen nicht korrekt dargestellt werden. Bei Grafik-Programmen ist das kein Problem, aber bei einiger Software, die ich für die Textkonsole habe. Die Ausgabe der Zeichen vorhandener Daten bei aufgerufenen Programmen ist korrekt, die Eingabe führt aber zu Problemen.

Bei Debian stable ist das Problem lösbar, indem sysvinit-core installiert wird. Das habe ich auch bei testing versucht, bekam aber dann die Meldung, dass neben einigen anderen Programmen synaptic und das x-login-Programm lightdm dafür gelöscht werden müssen.

synaptic ist nach meiner Erfahrung ein höchst komfortables Paketverwaltungsprogramm, auf das ich nicht verzichten will. Wieso ein solches Programm bei testing nicht im Zusammenhang mit sysvinit-core laufen soll, was es bei stable unproblematisch tut, ist für mich nicht nachvollziehbar. Als Arbeitsumgebung verwende ich xfce.

Gibt es hier einen systemd-Spezialisten, der auf tty1 bis tty6 quasi zu Hause ist und sich deshalb um die Nichtbeachtung der Kodierung durch systemd gekümmert hat? Wie kann dieser Bug von systemd umgangen werden?

[RobertDebiannutzer]

vielleicht hätte ich eine Lösung für sysvinit-core:
Was passiert, wenn Du zusätzlich libpam-elogind installierst? Am besten gleichzeitig mit sysvinit-core, denn die Umstellung von systemd auf sysvinit ist nicht so ganz trivial.

[MSfree]

Alles lief gut, bis auf das aus der Vergangenheit bekannte Problem, dass trotz der gewählten Hauptkodierung de_DE@ euro, also iso-8859-15, die Umlaute bei Nutzung der Textkonsolen nicht korrekt dargestellt werden.

Ich habe ehrlich geasgt keine Ahnung, was bei dir schief läuft. Der einzige Unterschied, den ich zwischen meinen Installationen und deiner sehe, ist, daß ich de_DE.UTF-8 statt iso-8859-15 verwende.

[JTH]

Was sagt denn ein

Code: Alles auswählen

# dpkg-reconfigure console-setup

? Dort sollte auch ISO-8859-15 ausgewählt sein. sysvinit-core zu installieren ist ja keine wirkliche Lösung für das Problem.

Generell würd ich aber auch eher dazu raten, überall einfach UTF-8 zu benutzen.

[KP97]

Wie kann dieser Bug von systemd umgangen werden?

Das halte ich, vorsichtig ausgedrückt, für ein Gerücht.
Das hat mit systemd absolut Null zu tun. Stelle Deinen Zeichensatz auf UTF-8 ein. Der ist seit Jahren Standard, und zeigt Dir selbstverständlich auch das Eurozeichen und sämtliche andere Sonderzeichen Deines ausgewählten Systemfonts.
Das behebt mit Sicherheit auch Deine Probleme in einem Terminal.

iso-8859-15 ist ein Relikt aus der Vorzeit und wird so gut wie überhaupt nicht mehr verwendet, siehe diese Tabelle:
https://w3techs.com/technologies/histor ... r_encoding

[Hans-Martin]

Leider gab es ohne Verständnis für meine Information, dass ich Konsolensoftware verwende - die vielleicht alt ist, aber hervorragend funktioniert - und für deren Datenverwaltung eine 1-Byte.Kodierung nötig ist, Hinweise auf das mir selbstverständlich bekannte UTF-8, welches für die von mir gesprochenen und geschriebenen Sprachen Deutsch, Englisch und Französisch nicht erforderlich ist.

Auch wurde offensichtlich nicht verstanden, dass iso8859-15 der Nachfolger von iso8859-1 ist. Letztgenannte Kodierung hatte nämlich kein Euro-Symbol. Es ist bei Durchsicht der Statistik eher merkwürdig, dass immer noch iso8859-1 verwendet wird.

Den Begriff "bug" habe ich deshalb verwendet, weil es keinen Sinn macht locales und Konsole-Kodierungen abzufragen und sie anschließend nicht zur Verfügung zu stellen. Bei Sonderzeichen wird bei systemd trotz entsprechender Konfiguration utf-8 generiert und dann falsch als zwei Zeichen dargestellt. Der Unterschied zu iso8859-n: Ab Dezimalwert 128 werden 2 bis 4 Byte verwendet. Wenn ich bei iso8859-15 einen Text mit französischen Akzentbuchstaben auf tty1 etc. schreiben will, tippe ich einfach Alt plus, mit dem Numblock, den zugehörigen Wert zwischen 128 und 255.

[JTH]

[ …] weil es keinen Sinn macht locales und Konsole-Kodierungen abzufragen und sie anschließend nicht zur Verfügung zu stellen.

Hast du, wie oben vorgeschlagen, nochmal überprüft, ob letztere richtig gesetzt ist?

Was sagt denn ein

Code: Alles auswählen

# dpkg-reconfigure console-setup

? Dort sollte auch ISO-8859-15 ausgewählt sein. […]

Mit systemd an sich dürfte das allerdings wirklich nix zu tun haben. Höchstens hat sich da mal etwas geändert, wie/wo/wann console-setup aufgerufen wird.

[Hans-Martin]

An JTH:
Danke für Dein Nachhaken. Ja, ich habe alle Pakete, die locales, Konsole und Tastatur beeinflussen, mit dpkg-reconfigure überprüft. Bevor ich das Forum belästige, versuche ich natürlich, mit den bordeigenen Mitteln weiterzukommen. Alle Tests waren positiv.

Bei stretch führt dieselbe Konfiguration mit Installation von sysvinit-core zum korrekten Zeichensatz auf den Textkonsolen. Da die aktuellen, von mir nicht nachvollziehbaren, Abhängigkeiten zu einer wahren Löschorgie bei der testweisen Installation von sysvinit-core geführt haben, ist aktuell eine Problemlösung wie bei stretch nicht gangbar. Selbst der Editor kwrite wurde deswegen "geschluckt".

[JTH]

Ich hab aus Interesse nochmal weitergesucht. Es scheint, dass setupcon aus console-setup zum falschen Zeitpunkt ausgeführt wird. Nach Anmeldung im TTY nochmal wie unten von Hand ausgeführt, scheint das Encoding überall zu stimmen. Fällt bei UTF-8 wohl nur nicht auf, weil UTF-8 überall der Default ist. Es gibt zu ähnlichen Problemen Bugreports zu console-setup, aber ohne richtige Lösung. Vielleicht ist das hier sogar einen Bugreport wert?

Ein

Code: Alles auswählen

[ -n "$PS1" ] && setupcon --current-tty

am Ende von /etc/profile hat bei mir dann geholfen.

[rhHeini]

Alles lief gut, bis auf das aus der Vergangenheit bekannte Problem, dass trotz der gewählten Hauptkodierung de_DE@ euro, also iso-8859-15, die Umlaute bei Nutzung der Textkonsolen nicht korrekt dargestellt werden. Bei Grafik-Programmen ist das kein Problem, aber bei einiger Software, die ich für die Textkonsole habe. Die Ausgabe der Zeichen vorhandener Daten bei aufgerufenen Programmen ist korrekt, die Eingabe führt aber zu Problemen.

Bei Debian stable ist das Problem lösbar, indem sysvinit-core installiert wird. Das habe ich auch bei testing versucht, bekam aber dann die Meldung, dass neben einigen anderen Programmen synaptic und das x-login-Programm lightdm dafür gelöscht werden müssen.

synaptic ist nach meiner Erfahrung ein höchst komfortables Paketverwaltungsprogramm, auf das ich nicht verzichten will. Wieso ein solches Programm bei testing nicht im Zusammenhang mit sysvinit-core laufen soll, was es bei stable unproblematisch tut, ist für mich nicht nachvollziehbar. Als Arbeitsumgebung verwende ich xfce.

Ketzerischer Vorschlag: schau Dir mal Devuan ASCII an. Ist im Prinzip Stretch, läuft mit sysvinit ohne systemd. lightdm, xfce und synaptic gehen.

Gruß, Rolf

[willy4711]

@Hans-Martin
Aus welchem zwingendem Grund musst du deine Kodierung eigentlich auf iso-8859-15 einstellen ?
Ist ein Versuch mit de_DE.utf8 keine Möglichkeit ?

[KP97]

@willy4711
Damit wurde ich doch auch schon abgebügelt....;-)

[Hans-Martin]

@JTH:
Ich habe manuell console-setup.sh aufgerufen: Umstellung auf das, was die Konfiguration besagt.

Im jeweiligen Runlevel wird als letzte Datei /etc.rc.local aufgerufen (ohne Inhalt passiert natürlich nichts). Eintrag des console-setup.sh-Aufrufs in rc.local: Keine Wirkung. Manueller Aufruf von rc.local: Umstellung der Kodierung erfolgt!

Also wird in der Startroutine rc.local nicht aufgerufen. Ich denke schon, dass ich das und die weiteren Auswirkungen melden werde.

Deine Idee mit dem Eintrag in /etc/profile ist sehr interessant. Ich habe dort bislang nur ein paar alias definiert.

Und an die, die mich auf UTF-8 ansprechen:

Wenn ich Datensätze habe, die Text mit Sonderzeichen enthalten (bei Kodierungen, denen ein Byte genügt, um alle erforderlichen Zeichen darzustellen), und diese verarbeite, z.B. mit Sortierroutinen, die
intern aus einem "ä" ein "ae", einem "ö" ein "oe" etc. machen, produziere ich bei Verwendung von UTF-8 für die Eingabe Datenschrott. Es wären andere Bibliotheken und andere Algorithmen erforderlich. Schaut euch doch dazu einfach die verschiedenen Bibliotheken für ncurses an.

[KP97]

Mit systemd wird die rc.local erst ausgeführt, wenn diese ausführbar gemacht wird, egal ob mit oder ohne Inhalt.
man systemd-rc-local-generator

Wir hatten den Hinweis zu utf-8 schon verstanden, war ja nur gutgemeint....

[JTH]

Ich habe manuell console-setup.sh aufgerufen: Umstellung auf das, was die Konfiguration besagt.

Das ist gut, wenn das für dich dann funktioniert. Das console-setup.sh ruft nämlich letztendlich auch nur das erwähnte setupcon auf.

Eintrag des console-setup.sh-Aufrufs in rc.local: Keine Wirkung.

Auch wenn /etc/rc.local ausführbar gemacht ist, scheint das beim Boot zu spät ausgeführt zu werden. Es läuft wohl doch auf eine Zeile in der /etc/profile oder /etc/bash.bashrc o.a. raus

[Hans-Martin]

@rhHeini
Danke für den Tip mit Devuan. Ich habe die Stretch entsprechende Distribution ascii installiert: Was bisher trotz Wahl bei der Installation von de_DE@euro nicht funktionierte, klappte auf Anhieb: Die automatische Generierung von Userverzeichnissen mit Umlauten. konkret Verzeichnis "Öffentlich". Bei Debian gibt es in diesem Fall immer ein UTF-8-Zeichen, das "Ö" darstellen soll, aber dann von der lokal eingestellten Kodierung nicht korrekt wiedergegeben werden kann. Das spielt für mich zwar im Ergebnis keine große Rolle, da ich aus Gewohnheit nie Datei- oder Verzeichnisnamen verwende, die nicht mit den niedrigen sieben Bits eines Bytes dargestellt werden können, aber es ist immerhin einfacher, ein "mv Öffentlich Oeffentlich" zu schreiben als die zwei auf der Tastatur nicht vorhandenen Sonderzeichen zu "Oe" zu ändern.

Das einzige kleine Problem bei Devuan ist das Fehlen der zahlreichen ergänzenden Paketbeschreibungen, die bei Debian existieren .

Ich habe seit ein paar Jahren parallel drei Versionen installiert. Jessie habe ich kürzlich gegen Buster mit UTF-8 ausgetauscht. Meine ncurses-Software (Textmodus) benötigt für die Textkonsolen eine Änderung der Quellkodes - andere zu linkende Bibliothekm andere Headerdatei, etc. -, derzeit prüfe ich, wieviel Sinn es macht, hier Arbeit zu investieren.

[guennid]

Nach meinen Beobachtungen, funktioniert auch ein Wechsel von devuan-ascii auf Debian-Stretch problemlos. Und von dort aus könnte man dann unter Umgehung von systemd auf ein funktionierendes buster kommen. Vorausgesetzt man baut sein System hier wie dort sukzessiv auf dem zunächst ausschließlich installierten Grundsystem ohne X auf. Login-Manager und DEs für den Aufbau der GUI verwende ich ebenfalls nicht. Ein nach meinem Dafürhalten entscheidendes Manko bei Debian ist halt, dass du das init-System bei einer Debian-Neuinstallation nicht auswählen kannst und der nachträgliche Ersatz von systemd durch sysvinit oder eines der alternativen Init-Systeme seit jessie dann nach meinen Beobachtungen eher schwierig ist.

Abgesehen von gnome ist mir mit udisks2 und davon abhängiger GUI-Software ein weiterer Kandidat aufgefallen, der ohne systemd nur auf Umwegen, wenn überhaupt, funktioniert. Möglicherweise kann man auf solchen (Um-)Wegen auch noch synaptic (womit ich keine Erfahrung habe) benutzen. Siehe dazu auch den recht aktuellen Thread zu synaptic/buster.

Grüße, Günther

[novalix]

Vor einigen Wochen habe ich in buster völlig problemlos von systemd auf sysv-init wechseln können. Es genügte die entsprechenden Pakete zu installieren.
Allerdings waren diese Installationen wirklich minimal. Es handelte sich um lxc-Instanzen (buster). Der Host war ebenfalls ein buster ohne X. Der lief allerdings weiter mit systemd.
Der Grund für die Umstellung war ein Bug im Zusammenspiel von systemd und apparmor, der dazu führte, dass manche daemons in den Containern nicht starten konnten. Mit sysv-init ging das problemlos.
Als der Bug gefixed war, habe ich die Maschinchen genauso problemlos wieder auf systemd umstellen können.

Bei umfangreichen Desktop-Installationen könnte das Prozedere durchaus schwieriger und fehleranfälliger sein. Ich war überrascht wie problemlos das für minimale Installationen durchzuführen war.

[MartinV]

Für einfache nicht-grafische Systeme kann ich bestätigen, daß der Wechsel einfach ist.
Der Vollständigkeit halber möchte ich erwähnen, daß auch runit mit dem Paket runit-sysv als init-System möglich ist.

Es ist mir bisher nicht gelungen, einen LXDE-Desktop ohne systemd auf Debian zu installieren, obwohl es auf anderen Systemen nicht von systemd abhängig ist. Da sind die Debian-Abhängigkeiten wohl noch nicht sauber definiert. (Mit elogind habe ich es aber noch nicht probiert, wäre noch einen Versuch wert.)

[guennid]

Vor einigen Wochen habe ich in buster völlig problemlos von systemd auf sysv-init wechseln können.

Was war mit systemd-shim und libpam-systemd?

Es ist mir bisher nicht gelungen, einen LXDE-Desktop ohne systemd auf Debian zu installieren

Schau mal, welcher Dateimanager installiert wurde. Abhängig von udisks2?

Wie gesagt, beim Umweg über devuan-ascii geht manches, was direkt anscheinend nicht geht.

Grüße, Günther

[Hans-Martin]

@guennid
Die Anpassung von systemd an die "klassischen" init-Routinen über die Installation von sysvinit-core war bei Stretch nicht mit Problemen verbunden. Bei Buster wurde ich durch die vorgeschlagene Löschorgie überrascht. Diese betraf in der Tat Grafikprogramme, eine entsprechende Änderung bei Systemen mit wenig Grafikprogrammen dürfte daher unproblematisch möglich sein.

Deine Idee mit dem Umstieg von ascii nach Stretch mit dem anschließenden Aufstieg zu Buster ist interessant. Devuan ascii ist aktuell meine Arbeitsumgebung, Buster mit UTF-8 dient Tests, um herauszufinden, was ich an der ncurses verwendenden Software ändern muss, und welche Methoden dafür anzuwenden sind. Man lernt dadurch Dinge, die in keinem "man" stehen.

Auch bei Devuan ascii blieb der Lerneffekt nicht aus. Ich nahm an, wegen der Parallele zu Stretch, dass ich Userverzeichnisse samt der dort enthaltenen Konfigurationen nach ascii umkopieren können würde. Bei der Installation war der übliche Hauptuser - ich verwende je nach Zweck unterschiedliche - angelegt worden. Trotz der deutschen Länder- und Sprachangabe erfolgten die Grafikangaben (Menü, Kopfzeilen) bei diesem nun auf einmal auf Englisch. Also: Umkopieren des Userverzeichnisses mit einem anderen Namen, beseitigen des Users, löschen von dessen Altverzeichnis, Neuanlage mit adduser: Kein Erfolg, englische Ausgaben. Habe ich irgendwelche anderen User angelegt, erfolgte alles auf Deutsch. Da dürfte bei der Erstinstallation etwas in einer Datenbank vermerkt werden, was man analog zu chronischen Krankheiten betrachten kann.

Ich hatte dabei als Displaymanager lightdm gewählt. Ich wechselte zu slim: Das Userverzeichnis des zuerst angelegten Users erschien auf der Grafikoberfläche mit deutschen Beschreibungen.

Die komfortable Dateiverwaltung mit synaptic war vor Jahren ein Grund, Debian zu finden und dort zu bleiben. Mein Einstieg in die Linuxwelt erfolgte in den 90er-Jahren mit SuSE 5.3. Das dortige Verwaltungsprogramm yast machte Softwareupdates extrem langsam, weil nach Beendigung einer Installation vor einer weiteren alles neu geladen wurde. Auf jeden Fall war die Besonderheit der Linux-Systeme deren individuelle Konfigurierbarkeit. Durch die stark gewordenen Abhängigkeiten von Programmpaketen untereinander, und nicht etwa nur vom Vorhandensein erforderlicher libraries, sind da einige Einschränkungen entstanden.