systemd blockiert boot...

[rsi]

Ich habe bis jetzt Debian Stretch ohne größere Problem einsetzen können (als Server, etc. pp. nichts mit Desktop... reine Console/SSH-Terminal Verbindung).
Doch nach einem Update meint systemd plötzlich, dass er nicht weiter booten kann, weil IRGEND EIN FEHLER aufgetreten ist. Nur, was für ein Fehler, warum wieso weshalb, danach suche ich mich langsam dämlich. Es gibt keine eindeutigen Grund, warum systemd das weiter booten verhindert.
Und ich bin langsam kurz davor, Debian für immer von meinerm Server zu schmeißen, weil es systemd benutzt, obwohl ich bisher von Debian als Server-System überzeugt war. Doch langsam geht das System immer mehr in Richtung "ab in die Tonne...".

Hat irgend jemand eine Idee, wie man herausfinden kann, warum systemd alles blockiert?
Mit journalctl -xb bekomme ich tausende Meldungen angezeigt, aber nicht einen eindeutigen Fehler, woraus man schließen könnte, warum systemd das System blockiert.
Festplatten, Dienste, Netzwerk laufen alle!

systemd ist der größte Müll, den man in Debian einfügen konnte!

[catdog2]

weil IRGEND EIN FEHLER aufgetreten ist.

Und ich bin langsam kurz davor, Debian für immer von meinerm Server zu schmeißen, weil es systemd benutzt, obwohl ich bisher von Debian als Server-System überzeugt war. Doch langsam geht das System immer mehr in Richtung "ab in die Tonne...".

systemd ist der größte Müll, den man in Debian einfügen konnte!

Worauf wartest du? Willst du überhaupt eine Lösung oder uns hier nur auf den Geist gehen?

Es gibt keine eindeutigen Grund, warum systemd das weiter booten verhindert.

Na irgendeinen wirds schon geben.

Hat irgend jemand eine Idee, wie man herausfinden kann, warum systemd alles blockiert?

Eine genaue Fehlerbeschreibung könnte evtl. vllt. helfen. Meine Glaskugel ist leider in Reparatur.

[cronoik]

Code: Alles auswählen

journactl --priority 3

[DeletedUserReAsG]

Ist das nicht dieser neue Schutzmechanismus? Wer nicht in der Lage ist, ‘nen Fehler auch nur zu lokalisieren, wird zum Schutz der restlichen Bevölkerung daran gehindert, weiterhin ’nen Server zu fahren?

scnr

[Radfahrer]

Ja genau, das ist das, in systemd eingebaute, sogenannte Pebcak-Modul.

[rendegast]

Erstmal ersetzen
systemd-sysv -> sysvinit-core + systemd-shim.
systemd-init bleibt weiterhin als Bootoption.


Auch
fstab mal auf Validität prüfen.
Evtl. Auskommentieren zBsp. swap-Einträge
(swap-Partitionen erkennt/verwendet systemd-init automatisch (soll zumindest))
initrd neu erstellen lassen, eventuell wird darin auf nicht mehr vorhandene / geänderte Devices Bezug genommen.




-------------------------------------------------------------------------------------------------------
Auf meinem VM-Host verdächtige ich systemd des sporadischen Aussetzens

Code: Alles auswählen

# journalctl | egrep "\-\- Reboot"
...
Apr 07 04:41:34 host systemd-journal[210]: Journal stopped
-- Reboot --
--
Apr 07 07:00:49 host systemd-journal[197]: Journal stopped
-- Reboot --
--
Apr 18 09:17:01 host CRON[32136]: pam_unix(cron:session): session closed for user root
-- Reboot --
--
Apr 21 09:17:01 host CRON[4144]: pam_unix(cron:session): session closed for user root
-- Reboot --
--
Apr 28 19:53:43 host systemd-journal[209]: Journal stopped
-- Reboot --
--
Apr 29 00:17:01 host CRON[3481]: pam_unix(cron:session): session closed for user root
-- Reboot --
--
May 01 09:17:01 host CRON[7253]: pam_unix(cron:session): session closed for user root
-- Reboot --

(insbesondere die beiden letzten nichtveranlaßten Reboot) <->
Neuboot mit sysv-init:

Code: Alles auswählen

# dmesg | grep omma
[Tue May  3 20:02:14 2016] Command line: BOOT_IMAGE=/boot/vmlinuz-4.5.0-0.bpo.1-amd64 root=UUID=ee52f4f8-93e7-43d8-8f9d-7bad14a8d2e9 ro ipv6.disable=1
[Tue May  3 20:02:14 2016] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.5.0-0.bpo.1-amd64 root=UUID=ee52f4f8-93e7-43d8-8f9d-7bad14a8d2e9 ro ipv6.disable=1
(letzte Boot-Zeit)

# uptime
 11:44:18 up 7 days, 15:42,  0 users,  load average: 0.00, 0.01, 0.05

Kommt jetzt natürlich darauf an, ob host
(i5, 4GB, mit USV abgesichert,
einzige Anwendung virtualbox 5 jessie-backports - 1 VM mit 1,5 GB RAM) weiter durchläuft.
- falls host doch die Tage rebootet, würde/müßte ich wieder Hardwarefehler in Betracht ziehen
( Netzteil? MB?
dmesg/Logs bezüglich Hardware unverdächtig,
RAM/Platte getestet soweit oK, und sollte sich im Log zeigen/andeuten)
- Auf meiner eigenen Maschine (jessie i386/amd64) habe ich keine Probleme mit systemd-init, uptime momentan 11Tage (amd64).
- Auf einer anderen Maschine (jessie i386) unterbleibt ein seltsames Verhalten von lxdm (auch das war ohne Log-Hinweise) seit Wechsel systemd-init -> sysv-init.

[NAB]

Wer Stretch auf Servern einsetzt, sollte doch sicherlich auch einen Debian Bugreport schreiben können?

[pferdefreund]

Auf einem Server setzt man stable ein. Alles andere ist - mutig und sollte nur von jemanden gemacht werden,der sich wirklich damit auskennt. Ich nicht - deshalb verwende ich stable und . (Punkt)

[cronoik]

Vielleicht koennen alle mal einen Gang runterschalten. Der Post des TE mag unsachlich sein, aber einige holen hier gleich die Pfloecke und einen Hammer heraus, wenn sie nur einen Post mit Testing und Server lesen. Sicherlich laesst sich in diese beiden Worte ein Spieleserver im www, mit lausigen Admin hineininterpretieren, aber solange es nicht dasteht, kann ich es auch lassen.

[ohnex]

Hi


@cronoik

ciao