[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [systemd] grafischen boot verhindern?



Marc Haber <mh+debian-user-german@zugschlus.de> wrote:
> On Thu, 27 Nov 2014 13:20:19 +0100, Marc Haber
> <mh+debian-user-german@zugschlus.de> wrote:

>> mein erstes sid mit systemd bootet, schaltet in den Grafikmodus und
>> stirbt.
>>
>> systemd.unit=multi-user.target schaltet, obwohl multi-user.target in
>> der systemd.special manpage als non-graphical dokumentiert ist, in
>> den Grafikmodus mit denselben Folgen wie ohne.

> Das liegt daran, dass kdm immer noch ein sysv-Initscript verwendet und
> nicht über eine systemd-Unit gestartet wird. Damit sind die symbolisch
> benannten systemd-targets nicht relevant, sondern die start/stop-Links
> in /etc/rc*.d. Und multi-user.target ist äquivalent zu
> runlevel2.target, und der startet alles, was im rc2.d definiert ist.

> Dummerweise sind runlevel[345].target ebenfalls äquivalent zu
> multi-user.target definiert. Somit gibt es keine Möglichkeit, beim
> Systemstart zu entscheiden, ob man kdm haben will, selbst wenn man
> sich vorher einen passenden Runlevel (bei mir ist es 3) so definiert
> hat.

Das allerdings ist ein Problem, das Sysvinit auch schon hat. Unter
Debian wird halt jeder *DM sofort gestartet, wenn er installiert ist, da
es kein separates Run-Level für den graphischen Boot gibt, wie es z.B.
schon seit jeher bei SuSE der Fall ist, weil die Debian-Philosophie war
"soll der Admin sich das halt selbst definieren, wir zwingen nichts auf"
und "wenn das Paket installiert ist, dann will der User wohl, dass der
Dienst darin gestartet wird".

Das verursacht jetzt die Schmerzen.

Wären die Run-Level vorher schon passend aufgeteilt gewesen, also z.B. 2
für Mehruser-Betrieb und 3 (oder 5) für Graphischen Desktop, dann würden
die automatischen Mappings von Run-Level auf Targets auch mehr Sinn
ergeben.

Leider ist es dafür 20 Jahr zu spät, das noch gerade zu biegen.

> Und ich bekomme immer mehr den Eindruck, als ob wir stur nach Kalender
> eingefroren hätten ohne dass sich das Releaseteam vorher klar darüber
> geworden ist, ob die Distribution als ganzes reif dafür ist. IMO ist
> sie dies vor allem wegen der nur halb gebackenen systemd-Integration
> der Fall.

Meiner Meinung nach wurde nicht zu früh eingefroren, sondern systemd
viel zu spät im Entwicklungszyklus als Default eingebracht. Das hätte
schon am Anfang von Testing-to-be-Jessie passieren müssen und nicht 3
Monate vor dem Freeze.

Leider diskutieren die Debianer ja gerne über persönliche
Empfindlichkeiten und theoretische Möglichkeiten und darüber, ob sie
noch der Erhalter der Reinen Unixoiden Lehre seien, während die Realität
fröhlich davon zieht. Und leider gibt es unter den Leuten "da draussen"
noch welche, die den bestehenden Keil mit Freude tiefer treiben, um ihre
eigenen Agenda zu puschen.

Und dann die "ich will nix auf meinem System haben, was von Poettering
und RedHat angefasst wurde"-Paranoiker, von denen die Hälfte nicht
verstanden hat, wie die Abhängigkeiten einer Binär-Distribution
funktioneren. Die ernsthaft fordern, von jedem Paket solle es auch einen
"-nosystemd"-Variante geben. Leute, die eigentlich ein Gentoo mit
USE-flags wollen, aber lieber die heimilige Wohltat einer
durchgetesteten Binär-Distribution haben wollen. Zu denen fällt mir nur
ein Kopfschütteln ein, solche Leute kann ich nicht mehr ernst nehmen.

Was in den Grabenkämpfen irgendwie aus dem Auge verloren wurde ist, dass
es jeden Mann/Frau an Deck braucht, um alle Dinge einer Distribution
zusammen arbeiten zu lassen.

Und so entzweiht man sich im schönen Kreise, argumentiert unendlich
darüber, ob systemd oder sysvinit oder upstart jetzt unter "our users
are our priority" fällt, ohne konkret etwas dafür zu tun, dass die
Distribution für jeden funktioniert.

Ich für meinen Teil finde, Debian gibt sich langsam der Lächerlichkeit
Preis, bzw. hat dies in dieser Diskussion schon lange.

S°

-- 
Sigmentation fault. Core dumped.


Reply to: