Re: [systemd] grafischen boot verhindern?
Marc Haber <mh+debian-user-german@zugschlus.de> wrote:
> On Mon, 1 Dec 2014 15:48:57 +0100, Sven Hartge <sven@svenhartge.de>
> wrote:
>>Marc Haber <mh+debian-user-german@zugschlus.de> wrote:
>>> On Mon, 1 Dec 2014 12:38:17 +0100, Sven Hartge <sven@svenhartge.de>
>>> wrote:
>>
>>>> Das beim Übergang von sysvinit zu systemd in Debian das
>>>> Ursprungsproblem des Threads auftritt? Das ist natürlich unschön, ist
>>>> in dem Fall vom KDM-Maintainer einfach dadurch zu beheben, dass er
>>>> ein Unit-File für systemd für kdm bereitstellt. Dann funktioniert die
>>>> Auftrennung in Multi-User und Graphischer Desktop wieder wie
>>>> gewünscht.
>>
>>> Das ist das offensichtliche Problem, das sich dann richtig eklig
>>> zeigt, wenn der Rechner zwar ordentlich bootet, dann aber beim Starten
>>> des X-Servers verstirbt.
>>
>>Das Grundproblem der nicht sauber getrennten Runlevel für Multi-User und
>>Graphischer Desktop in Debian kann man aber schwerlich systemd anlasten,
>>wenn man ehrlich ist, denn dieses Problem exisitiert ja schon bei
>>sysvinit seit Anbeginn.
> sysvinit hat Nummern für die Runlevels, die erstmal keine Aussage
> machen. systemd hat symbolische Namen wie "multi-user" (explizit als
> non-graphical definiert) und "graphical" und hält sich nicht an seine
> eigene Aussagen.
Im Default Debian sind die RunLevel 2 bis 5 aber identisch.
>> Bei sysvinit hättest du dann entweder in Runlevel 1 oder via
>> "init=/bin/bash" im Brachial-Rettungsmodus ohne Netzwerk starten müssen,
>> um das Init-Script von KDM lahmzulegen, um dann einen nicht-graphischen
>> Boot zu erhalten.
> Ich hätte auch einfach im Runlevel 3 starten können, der auf meinen
> Kisten exakt für so einen Fall seit Jahr und Tag als "ohne DM"
> definiert ist.
In deinem speziellen Fall, ja.
Ich könnte z.B. SuSE nachgebaut haben und in 5 Multi-User mit
graphischen Desktop und in 3 Multi-User mit Textkonsole gelegt haben.
Und das ist gerade ja das Problem in der Umstellung. systemd baut im
Moment nur eine saubere Migration vom RunLevel-Default nach und verhält
sich darin identisch zu sysvinit. Zumindest mein Laptop und meine zwei
Arbeitsplatz-PCs verhalten sich nach Installation von systemd nicht
anders wie vorher mit sysvinit.
Schwierig wird es, wenn die Leute ihre Runlevel angepasst haben. Dann
brauchst du irgendeine Automatik, um diese Anpassung auf die Targets von
systemd zu migrieren. Die hat bisher nur leider keiner geschrieben. (
Und ich glaube auch, dass es nahezu unmöglich sein dürfte, hier eine
One-Size-Fits-All-Lösung zu finden.)
Was vermutlich daran liegen dürfte, dass die beiden großen
Enterprise-Distributionen (RHEL und SLES) und deren Entwickungsversionen
(Fedora und OpenSuSE) schon immer eine deutliche Trennung in den
Runleveln hatten, so dass hier die Abbildung eines sinnvollen Defaults
von Runleveln auf Targets einfacher möglich ist.
Bei dir knallte es jetzt, weil X von Sid deine Hardware nicht mag. Du
wolltest dann den systemd-Weg des Debugging benutzen und hast ihm gesagt
"bitte starte in der Text-Konsole". Leider hat das KDM-Paket einen Bug
und KDM wird dennoch gestartet, weil alle Legacy-LSB-Init-Scripte in das
multi-user.target gemappt sind.
Hier wieder die Frage: was will das systemd-Paket machen? Aus dem
init-Script von KDM geht nicht hervor, dass es in das graphical.target
gehört. Diese Information läßt sich nur in den nativen systemd-Units
transportieren. Oder manuell anlegen.
Wenn ich hier deine initialen Debugging-Schritte nachvollziehe, dann
funktioniert das mit LightDM so, wie es beworben wird: ich lande im
Multi-User-Text-Modus.
Ich für mich kann also sagen: Jo, löppt.
Aber ist ein Fehlerbericht wie von dir nicht gerade auch der Zweck vom
Freeze? Nicht ständig neue Versionen nachzukippen sondern das vorhandene
zu stabilisieren?
Leider, ich sagte es ja schon, wurde systemd meiner Meinung nach viel zu
spät zum neuen Default gemacht und die Diskussionen und der FUD auf
beiden Seiten führten dazu, dass nur sehr wenige Leute den neuen Default
testeten, so dass Fehler, wie deiner, erst sehr spät sichtbar werden,
obwohl sie schon länger da sind und nur noch nicht aufgefallen waren.
_Das_ macht mir Sorgen, dass die Leute auf Grund der eigenen
Scheuklappen es nicht einfach mal ausprobieren und Fehler berichten,
damit diese behoben werden können oder zumindest dokumentiert sind.
Grüße,
Sven.
--
Sigmentation fault. Core dumped.
Reply to: