[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 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.

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.

>> 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.

> Das finde ich echt frech, dass systemd sowas darf. Und andere Pakete
> müssen sich einen abbrechen um seamless updates zu ermöglichen.

Das _ist_ extrem unschön, da stimme ich dir sofort zu. systemd bricht
bei den Runleveln nun mal sehr deutlich mit dem bisherigen Konzept,
welches schwerlich aufeinander automatisch umzumappen ist.

Was willst du machen? Wie willst du es lösen?

Um so wichtiger ist es, dass der Init von bestehenden Systemen nicht
automatisch auf systemd umgeändert wird, sondern nur durch expliziten
Willen des Admins. Der dann hoffentlich weiß, was er macht.

S°

-- 
Sigmentation fault. Core dumped.


Reply to: