Re: [systemd] grafischen boot verhindern?

[Sven Hartge <sven@svenhartge.de>]

Marc Haber <mh+debian-user-german@zugschlus.de> wrote:
> On Sun, 30 Nov 2014 16:02:15 +0100, Sven Hartge <sven@svenhartge.de> wrote:
>>Christian Knoke <chrisk@cknoke.de> wrote:
>>> Sven Hartge schrieb am 30. Nov um 14:04 Uhr:

>>>> 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.
>>
>>> Keine feste Aufteilung, aber vielleich ein Tool, mit dem ich mir
>>> meine RunLevel selber definieren kann, welche Dienste in welchem
>>> RunLevel starten.
>>
>>Gibt es ja. Nennt sich update-rc.d. Oder du editierst die LSB-Header
>>in den Init-Scripten und passt dann die inittag ab, um z.B. Runlevel 3
>>statt 2 per default zu starten.
>>
>>Hat natürlich den Nachteil, dass bei jedem Update des jeweiligen
>>Paketes das Init-Script als verändert gesehen wird und du das manuell
>>abnicken musst bzw. die Änderungen manuell mergen musst.
>>
>>So gesehen erachte ich es schon als Debians Design-Fehler, dass die
>>Display-Manager auch in Runlevel 2 stehen und der graphische Desktop
>>kein separates Runlevel hat, so dass jeder, der das separieren will,
>>erst einmal manuell herumbasteln muss.

> Dieses manuelle Herumbasteln ist gar kein Problem gewesen (exakt ein
> Kommandozeilenaufruf), bis systemd kam.

Wo genau ist jetzt die Problemstelle?

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.

Oder ist das Problem, was du ansprichst, eher genereller Natur, dass
Änderungen des Admins an den Runleveln nicht sauber übernommen werden?
Das ist definitiv ein Problem, allerdings sehe ich aktuell nicht, wie
man das programmatisch lösen könnte. AFAIK wird in debian-devel derzeit
diskutiert, den Admin zu informieren, dass er selbst Hand anlegen muss,
wenn er /etc/inittab und /etc/rc?.d verändert hat.

Was den Kommandozeilenaufruf angeht: Den gibt es bei systemd auch,
entweder, in dem man diepassende Unit in das passende Target.wants
verlinkt oder ein Override-Config-File erstellt, dort das [Install]
anpasst und dann via "systemctl enable" den symlink erzeugen läßt.
Zugegeben, es sind ggfls. zwei Schritte, aber das wird ja wohl kaum
jemanden zum Straucheln bringen.

Oder willst du sagen, dass man als Admin unter systemd jetzt gar nicht
mehr manuell an den Inhalten der Runlevel bzw. Targets herumbasteln
kann? Das sehe ich allerdings nicht, meine manuell Änderungen an den
Inhalten der Targets wurden bisher immer klaglos genommen.

S°

-- 
Sigmentation fault. Core dumped.