Jessie systemd emergency mode: Eigenschaften?

[bullgard]

Hallo debianforum.de,
Nach Neuinstallation von Wheezy und Aktualisierung auf Jessie startet mein T43 ungefähr jedes dritte Mal in den systemd emergency mode.
Siehe dazu auch freedesktop.desktop.org/wiki/Software/systemd/Debugging/
Wie auch in viewtopic.php?f=32&t=153538&hilit=syste ... gency+mode berichtet, kündigt er sich durch folgende Meldung an: "

Welcome to emergency mode! After logging in, type "journalctl -xb" to view system logs, "systemctl reboot" to reboot, "systemctl default" to try again to boot into default mode

.'
Der systemd emergency mode wurd hier im Forum noch ein paar Mal erwähnt.
Welche Eigenschaften hat der systemd emergency mode?
Mein Eindruck beim Googeln war, daß sich die Eigenschaften des systemd emergency mode in der Vergangenheit stark (distributionsspezifisch?) geändert haben und sich wohl in neuen Debian-Veröffentlichungen weiter ändern werden.
Eine aussgekräftige Beschreibung des Jessie systemd emergency mode habe ich beim Googeln nicht gefunden.
Mit freundlichen Grüßen
bullgard

[smutbert]

Es existieren 2 systemd units mit diesem Namen
- emergency.target
- emergency.service

Targets sind gewissermaßen das Gegenstück zu den Runleveln und wenn man sich das emergency.target mit

Code: Alles auswählen

$ systemctl show emergency.target

ansieht, sieht man dass schlicht keine Dienste und kaum sonstige units gestartet werden (keine Zeile Wants=… und nur ein Requires=…) und dass es mit sysinit.target in Konflikt steht (das wiederum sehr viele grundlegende Dinge erledigt bzw. starten würde). Das einzige was offensichtlich gestartet wird ist emergency.service. das einen einfachen Textlogin zur Verfügung stellt.

Vergleicht man das mit dem Standardtarget graphical.target. das (auf meinem System)

Code: Alles auswählen

$ systemctl show graphical.target
[…]
Requires=multi-user.target
Wants=gdm.service accounts-daemon.service systemd-update-utmp-runlevel.service kdm.service mysql.service LCDd.service
[…]

startet, wobei das multi-user.target wieder einige weitere units startet:

Code: Alles auswählen

$ systemctl show graphical.target
[…]
Requires=basic.target
Wants=systemd-update-utmp-runlevel.service kdm.service mysql.service LCDd.service remote-fs.target cron.target ssh.service avahi-daemon.service NetworkManager.service binfmt-support.service mpd.service rc-local.service dbus.service systemd-ask-password-wall.path getty.target
[…]

und das basic.target wieder eine Reihe von units von startet, usw.

[bullgard]

Hallo smutbert,
ja, so kann man die Eigenschaften des systemd emergency mode erforschen. Mühsam, aber es geht.
Ich habe nun einen Überblick über den systemd emergency mode gewonnen und kann selbst auf dem bechriebenen Wege weiter vordringen.
Du hast mir sehr geholfen.
'

Code: Alles auswählen

man systemd.special'

: "

NAME: systemd.special - Special systemd units. SPECIAL SYSTEM UNITS: …
emergency.target: A special target unit that starts an emergency shell on the main console. This unit is supposed to be used with the kernel command line option 'systemd.unit=' and has otherwise little use.

"
Vielen Dank!
Gruß
bullgard

[smutbert]

Zumindest hast du bei deinen Untersuchungen den Vorteil, dass das emergency.target recht übersichtlich ist:

Code: Alles auswählen

$ cat /lib/systemd/system/emergency.target
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

[Unit]
Description=Emergency Mode
Documentation=man:systemd.special(7)
Requires=emergency.service
After=emergency.service
AllowIsolate=yes

Also viel passiert da wirklich nicht. Die einzige Besonderheit ist eigentlich das AllowIsolate, dank dem man beim Aufrufen von emergency.target dafür sorgen kann, dass alles, was nicht Teil von emergency.target ist, also alles außer emergency.service gestoppt wird. Der Befehl dafür

Code: Alles auswählen

# systemctl isolate emergency.target

war mir zB genauso neu, wie die Idee/Tatsache, dass das bei vielen anderen targets nicht geht.

[bullgard]

Prima! - Danke!
Gruß
bullgard

[bullgard]

Hallo debianforum.de,
Mein Computer T43 startet in ~50% der Fälle nicht Jessie SLiM und nach meiner Anmeldung Xfce, sondern landet im systemd emergency mode. Die praktisch erste rote Fehlermeldung, die '

Code: Alles auswählen

~# journalctl -xb

' ausgibt, ist

<Zeitstempel> <Benutzername> T43 kernel:ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen

Diese Fehlermeldung wurde 2008 sehr ausführlich bei Red Hat diskutiert und resultierte in einen (Red-Hat-)Patch.
Wenn mein Computer T43 ohne Fehlermeldung gestartet ist, ich mit ihm gearbeitet habe und ich ihn mittels Xfce-Anwendungsmenü > Abmelden > Ruhezustand in den Winterschlaf (ACPI-Zustand S4) schicke und viel später den Ein-/Ausschalter drücke, dann fährt mein Comupter hoch, übergeht das SLiM-Anmeldefenster und zeigt mir Xfce an. Ich kann normal arbeiten. Das gilt auch, wenn ich den Computer schon einmal oder mehrere Male aus dem Winterschlaf geholt habe. Jedenfalls hat das bisher zehn Mal hintereinander funktioniert.
Wie kann ich durch Kenntnis dieser Tatsache die Fehlersuche einkreisen?
Mit freundlichen Grüßen
bullgard

[NAB]

Gute Frage!

Ehm ... ich habe gerade nach "SLiP" gegoogelt ... und sah einige hübsche Damen in Unterwäsche. Okay, also, was ist "SLiP"? Verbindest du dich ernsthaft mit einem altertümlichen Modem?

Du hast kürzlich einen Thread zu Systemd eröffnet, mit einem Link auf einen Bug in Debian. Ich dachte eigentlich, du hättest dein Problem bereits identifiziert ... das scheint aber überhaupt nicht der Fall zu sein, oder?

Code: Alles auswählen

ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen

Die eine Zeile ist relativ nichtssagend. Da ist eine Festplatte/DVD-Laufwerk/USB-Stick "eingefroren". Üblicher Weise wird dann ein Reset-Kommando an das Laufwerk geschickt, und es reagiert wieder. Das könnte eine falsche Fährte sein.

Schau dir mal mit

Code: Alles auswählen

dmesg | grep ata1

an, was "ata1" überhaupt für ein Gerät ist, und wie die vollständige Fehlermeldung aussieht. Und dann kontrolliere mal, ob diese Meldung eventuell immer auftaucht, also auch, wenn der Computer problemlos bootet. Eventuell wird sie im Fehlerfall nur angezeigt ... eh ... weil sie halt da ist ... und die Fehlerursache ist eine andere.

Aber deine Entdeckung ist interessant. "Eigentlich" sollte zwischen S4 und S5 kein Unterschied bestehen. Da scheint aber doch einer zu sein. Die Frage ist, ob dieser Unterschied im BIOS hinterlegt ist, oder ob er in Debian besteht. Um das herauszukriegen, schlage ich folgendes Vorgehen vor:
1) Nimm den Akku raus - damit das Gerät nicht noch eine "heimliche" Stromversorgung hat.
2) Zieh den Stromstecker raus und warte ein paar Minuten, damit flüchtige BIOS-Inhalte gelöscht werden.
3) Starte den Computer, bis er erfolgreich bootet.
4) versetze ihn in den S4.
5) Zieh den Stromstecker wieder raus, kurz warten, wieder rein.
6) Startet Debian jetzt immer noch?
7) Wiederhole 4-6 einige male, um zu testen, ob es reproduzierbar ist.

Wenn das geht, dann liegt es eindeutig am Bootprozess von Debian, eventuell wirklich an Systemd.

Wenn es nicht geht, dann wird beim Erreichen von S4 irgendwas im BIOS hinterlegt, was den Fehler verhindert.

[bullgard]

Hallo NAB,

Ehm ... ich habe gerade nach "SLiP" gegoogelt ... und sah einige hübsche Damen in Unterwäsche. Okay, also, was ist "SLiP"? Verbindest du dich ernsthaft mit einem altertümlichen Modem?

Statt SLiP lies SLiM.

Du hast kürzlich einen Thread zu Systemd eröffnet, mit einem Link auf einen Bug in Debian. Ich dachte eigentlich, du hättest dein Problem bereits identifiziert ... das scheint aber überhaupt nicht der Fall zu sein, oder?

Die Fehlermeldung, die mein T43 aussendet, habe ich mitgeteilt. Sie ist sicherlich ein Problem. Ob sie _das_ Problem ist, weiß ich nicht. Ich denke aber, daß ich der Fehlerursache nähergekommen bin als beim letzten Thread.

Code: Alles auswählen

ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen

Die eine Zeile ist relativ nichtssagend. Da ist eine Festplatte/DVD-Laufwerk/USB-Stick "eingefroren". Üblicher Weise wird dann ein Reset-Kommando an das Laufwerk geschickt, und es reagiert wieder. Das könnte eine falsche Fährte sein.
Schau dir mal mit

Code: Alles auswählen

dmesg | grep ata1

an, was "ata1" überhaupt für ein Gerät ist.

ata! ist eine SATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0x1810 irq 14 ATA-8 SAMSUNG HM160HC LQ100-10 max UDMA/100 Festplatte mit 312 Mio Sektoren. Multi 16: LBA48 configured for UDMA/100

, und wie die vollständige Fehlermeldung aussieht.

". "Die vollständige Fehlermeldung" ist eine Zeile lang, und die habe ich gepostet. Oder meintest Du das gesamte Journal? Das ist ellenlang. Oder meinst Du die Ausgabe des Befehls '~$ dmesg | grep ata1?
Ich habe übrigens festgestellt, daß der Befehl '~$ dmesg | grep ata1?' auch in den Fällen, in denen ich auf die Schnelle keine Computerfehler beim Bedienen merke (z. B. kann ich im Internet surfen), zu verschiedenen Zeiten verschiedene Meldungen ausgibt. In einem Fall ist die Ausgabe 15 Zeilen lang und beinhaltet auch die Zeile

Code: Alles auswählen

ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen

. Im 2 Fall ist die Anzahl der ata1.00-Ausgabezeilen wesentlich länger (villeicht doppelt so lang) und man erkennt, daß der Computer 7 Mal versucht, die Festplatte einzurichten. Fall 1 endet mit den 2 Zeilen

Code: Alles auswählen

ata1.00:device reported invalid CHS sector 0
ata1: EH complete.

Dadurch kann ich meine Überzeugung, daß das Auftreten der Zeile

Code: Alles auswählen

ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen

ein Kriterium für nicht erfolgreiches Booten ist, nicht mehr aufrecht erhalten.

Und dann kontrolliere mal, ob diese Meldung eventuell immer auftaucht, also auch, wenn der Computer problemlos bootet. Eventuell wird sie im Fehlerfall nur angezeigt ... eh ... weil sie halt da ist ... und die Fehlerursache ist eine andere.

Die Fehlermeldung taucht im Journal manchmal auch auf, wenn der Computer erfolgreich gebootet hat.

Aber deine Entdeckung ist interessant. "Eigentlich" sollte zwischen S4 und S5 kein Unterschied bestehen. Da scheint aber doch einer zu sein. Die Frage ist, ob dieser Unterschied im BIOS hinterlegt ist, oder ob er in Debian besteht. Um das herauszukriegen, schlage ich folgendes Vorgehen vor:
1) Nimm den Akku raus - damit das Gerät nicht noch eine "heimliche" Stromversorgung hat.
2) Zieh den Stromstecker raus und warte ein paar Minuten, damit flüchtige BIOS-Inhalte gelöscht werden.
3) Starte den Computer, bis er erfolgreich bootet.
4) versetze ihn in den S4.
5) Zieh den Stromstecker wieder raus, kurz warten, wieder rein.
6) Startet Debian jetzt immer noch?
7) Wiederhole 4-6 einige male, um zu testen, ob es reproduzierbar ist.
Wenn das geht

Das geht. Ich habe den Zyklus 4) bis 6) 6 Mal erfolgreich durchlaufen.

, dann liegt es eindeutig am Bootprozess von Debian, eventuell wirklich an Systemd.
Wenn es nicht geht, dann wird beim Erreichen von S4 irgendwas im BIOS hinterlegt, was den Fehler verhindert.

Bei diesem Computer funktioniert Copy&Paste vom uxterm zum Eingabfeld von paste.debian.net manchmal nicht. Das erschwert die Kommunikation mit einem entfernten Helfer.
Gruß
bullgard

[NAB]

Welcher ist denn dieser "andere Thread"? Sollte man den auch gelesen haben?

Holla, das ist ja noch eine gute alte IDE-Festplatte. Die könnte natürlich mittlerweile einfach Anlaufschwierigkeiten haben. Hast du dir die Smart-Werte mal angeguckt?

Von Systemd Logs habe ich keine Ahnung, aber diese exception Emask Fehler treten normalerweise nicht alleine auf. Die sehen so aus:
http://askubuntu.com/questions/133946/a ... -dangerous
oder so:
https://bbs.archlinux.org/viewtopic.php?id=133339
Beachte, dass nicht in jeder Zeile ein "ataX" zu finden sein muss.
Es könnte auch etwas Laufwerksspezifisches sein:
https://www.google.de/?gws_rd=ssl#q=exc ... sk+HM160HC

Du machst das schon ganz richtig, diese ata1-Fehler näher zu erforschen. Aber dafür ist der Kontext wichtig, in dem diese einzelnen Zeilen auftreten. Probiere mal

Code: Alles auswählen

dmesg -T | grep ata1

Das zeigt dir verständliche Zeitangaben an.
In der kompletten Ausgabe von

Code: Alles auswählen

dmesg -T

kannst du dann danach suchen und dir den Kontext angucken und mit etwas Geschick auch nach der gesuchten Uhrzeit "grep"pen.

Die andere Frage ist, warum diese Fehler jetzt auf einmal mit Jessie auftauchen. Da kann ich nur vermuten.

Ich vermute, die Fehler tauchen schon länger auf, aber seit Jessie sind sie so fatal, dass sie das Booten unterbrechen. Das könnte daran liegen, dass Systemd versucht, alles "sofort" zu starten, während deine alternde Festplatte etwas mehr Zeit braucht, um sich von den Freezes zu erholen.

Es könnte auch sein, dass udev beim Booten ein paar neumodische Smart-Befehle an die Platte schickt, die sie meistens zum Einfrieren bringt. Es gab ähnliche Fälle in der Vergangenheit.

Es könnte auch sein, dass diese exception Emask Fehler gar nichts mit dem Problem zu tun haben. Versuch mal herauszukriegen, ob du einen zeitlichen Zusammenhang findest.

Und kannst du nicht einfach mal über das Boot-Menü von Grub versuchen, per Sysvinit zu starten?