staging.inyokaproject.org

Ähm

pepre schrieb:

Dieser Artikel wird momentan von pepre erstellt. Als Fertigstellungsdatum wurde der 31.02.2014 angegeben.

 	21. Januar 2015 15:39 :   Fertigstellung auf 31.2. gelegt :-) 

Besser wäre 01.04., als Aprilscherz und so... 😀 ♥

Dieser Hinweis zu rc-local ist in Verbindung mit Utopic Unicorn und späteren Versionen nicht mehr relevant.

Ein entsprechendes Unit ist bereits vorhanden und kann benutzt werden:

• /lib/systems/system/rc-local.service

auch wenn ein relevanter Eintrag in

• /lib/systems/system/multi-user.target.wants

noch fehlt - dieser ist ab Vivid Vervet vorhanden (wenn auch noch fehlerhaft!).

gruß syscon-hh

Bin nicht ganz sicher, ob das hier der richtige Ort ist, aber ich starte mal: Seit dem letzten neuen Kernel 3.19.0-9-generic bei vivid startet mein systemd Normalstart nicht mehr, der Bootprozess hängt sich auf oder erzeugt flackernde Bildschirme. Wenn ich hingegen mit upstart boote, komme ich ganz normal durch. [Bis ich das herausgefunden hatte, hat es allerdings lange gedauert, da ich den Fehler im Kernel selbst vermutet habe und alle mögliche Kernel-Varianten rückwärts bis 3.18.0-12-generic versucht habe, die sich auch starten ließen.]

Kann man upstart als Standard einstellen, bis der Fehler behoben ist?

Wenn ja, wo macht man das?

Das ist hier (eigentlich) die falsche Stelle für Support. Grundsätzlich ist der Ansatz "Ich nehm Upstart erstmal wieder" falsch, es löst nicht das Problem sondern verschiebt es bestenfalls. Eventuell hilft es KMS mal zu deaktivieren und quiet beim Boot wegzumachen, dann solltest du sehen was wo wann wie und warum passiert.

mfg Stefan Betz

Nur zur Info: Der Light Display Manager hat mit systemd nicht gebootet, habe GNOME Display Manager installiert, jetzt läuft alles normal, egal ob systemd oder upstart

Diskussion: im wiki Text durchgängig "systemd" oder "Systemd" ?

u1000 schrieb:

Diskussion: im wiki Text durchgängig "systemd" oder "Systemd" ?

Siehe systemd - Spelling 🇬🇧:

Yes, it is written systemd, not system D or System D, or even SystemD. And it isn't system d either. Why? Because it's a system daemon, and under Unix/Linux those are in lower case, and get suffixed with a lower case d. And since systemd manages the system, it's called systemd. It's that simple. [...]

Für mich ist damit alles gesagt.

Abschnitt rausgenommen, da 14.10 in Kürze veraltet:

Die Installation erfolgt bei Ubuntu 14.10 über das folgende Paket:

• systemd

Befehl zum Installieren der Pakete:

sudo apt-get install systemd 

Oder mit apturl installieren, Link: apt://systemd

Dies installiert die Dateien, die systemd braucht. Allerdings übernimmt es damit noch nicht den Systemstart. Dies geschieht erst, wenn man ein weiteres Paket installiert:

• systemd-sysv

Befehl zum Installieren der Pakete:

sudo apt-get install systemd-sysv 

Oder mit apturl installieren, Link: apt://systemd-sysv

–> EDIT: jetzt in den Abschnitt Problembehebung geschoben, damit die Info nicht verlorengeht.

Hallo,

demnach könnte der Artikel auch um "getestet: Vivid" erweitert werden, oder?

Was ist denn sonst so Stand der Dinge bzgl. Fertigstellung?

Gruß, noisefloor

noisefloor schrieb:

Was ist denn sonst so Stand der Dinge bzgl. Fertigstellung?

ZZt habe ich viel zu wenig Zeit, um mich dran zu setzen. Könnte sein, dass das in ca. drei Wochen besser wird, muss aber nicht.

Es sind ja oben einige wichtige Ergänzungen/Konkretisierungen genannt. Die müssen unbedingt noch rein. Das kann tun, wer will, ich beharre da auf keinem Recht als "Erstautor", falls das im Raume stehen sollte. Zudem habe ich kein Ubuntu, um ggf spezifische Fallstricke zu suchen (ich bekomme sie auch nicht mit, weil ich in anderen Brettern supporte). Bei mir läuft seit einem Jahr Jessie, und da tut systemd einwandfrei, wenn auch gewöhnungsbedürftig.

noch nicht unter 15.04 getestet:

• Grafisches Werkzeug

(tu ich auch nicht, ich liebe die console ☺)

• /etc/modules

(kann ich nicht beurteilen)

• /etc/rc.local

ist recht nebulös und so nicht verständlich. Wir brauchen hier den klaren Hinweis, dass

1. rc.local mit system ausgedient hat

2. dass man sie dennoch "nachinstallieren" oder "aktivieren" kann

3. dass es irgendeinen Bug in 15.04 gibt –> kurze präzise Problembehebung

Zum Bug: eins meiner Syteme startet unter 15.04 die rc.local normal mit, ein anderes musste ich korrigieren...

u1000 schrieb:

noch nicht unter 15.04 getestet:

• Grafisches Werkzeug

(tu ich auch nicht, ich liebe die console ☺)

systemd-ui funktioniert. Hab' ich gehört. 😉

• /etc/rc.local

ist recht nebulös und so nicht verständlich. Wir brauchen hier den klaren Hinweis, dass

1. rc.local mit system ausgedient hat

2. dass man sie dennoch "nachinstallieren" oder "aktivieren" kann

Ich habe seit Jahren einiges selbsteingetragenes drin, das, soweit wie ich das sehe, nach wie vor darüber funktioniert, sprich der Zusatz zur Abfrage einer rc.local unter systemd arbeitet.

3. dass es irgendeinen Bug in 15.04 gibt –> kurze präzise Problembehebung

Wie jetzt, Du willst einen Bug? 😉

/etc/modules wird einfach verlinkt nach /etc/modules-load.d/modules.conf, sonst scheinbar keine Änderungen. Die *.conf-Dateien in /etc/modprobe.d behalten ihre Gültigkeit, weil dort keine Kernelmodule geladen werden, sondern lediglich Optionen für bereits geladenen Module übergeben werden.

Wenn ich das richtig verstehe, dann ist das Reaktivieren der rc.local nichts weiter als ein weiterer Dienst (im Sinne einer .service-Datei), die systemd anweist /etc/rc.local als Skript beim Systemstart auszuführen - siehe /lib/systemd/system/rc.local.service.

Jetzt müsste ich das nur noch mit Quellen belegen 😬

mrkramps schrieb:

Jetzt müsste ich das nur noch mit Quellen belegen

• systemd archlinux

• systemd archlinux

• systemd DEBIAN (nur bedingt hilfreich)

Wenn ich das richtig verstehe, dann ist das Reaktivieren der rc.local nichts weiter als ein weiterer Dienst (im Sinne einer .service-Datei), die systemd anweist /etc/rc.local als Skript beim Systemstart auszuführen - siehe /lib/systemd/system/rc.local.service.

Es muss der "rc-local.service" direkt - nicht jedoch der Link benutzt werden.

Um diesen Dienst / Service aktivieren zu können, benötigt das Skript noch einen

• "Installations-Kandidaten"

Dazu muss man im Skript selbst (unten) noch ergänzen

[Install]
WantedBy=multi-user.target

bevor man es mit

• sudo systemctl enable rc-local.service

aktiviert - das war mein Hinweis auf "fehlerhaft".

Je nach Verwendung kann es angebracht sein, dieses statt "multi-user.target" zuzuordnen, eine andere Kathegorie zu setzen / zu wählen.

Was möglich ist und wie man es einsetzt, hatte ich auch hier beschrieben

• Datei für systemd erstellen

gruß syscon-hh

syscon-hh schrieb:

Dazu muss man im Skript selbst (unten) noch ergänzen

[Install]
WantedBy=multi-user.target

bevor man es mit

• sudo systemctl enable rc-local.service

aktiviert - das war mein Hinweis auf "fehlerhaft".

Ja, das habe ich so auch verstanden und kann es im wiki ergänzen. Je nach "Reparatur"- Methode ist aber ein

sudo systemctl reenable rc-local.service

notwendig.

Es muss der "rc-local.service" direkt - nicht jedoch der Link benutzt werden.

Das habe ich noch nicht ganz verstanden...

Viele Grüße u1000