Arch Linux

systemd journald - Fehlermeldungen beim booten

cipher

Hallo zusammen,

Ich habe eine Fehlermeldung beim Hochfahren meines Notebooks. Da durch die SSD der Bootvorgang so schnell durchrattert ist es nicht mehr möglich die Bootmeldungen zu lesen. Anhalten des Bootvorganges gleicht einem Glückspiel um die richtige Millisekunde zu erwischen.

Gibt es keine Möglichkeit die Ausgabe des Bootvorganges in eine Datei umzuleiten, so das man diese dann durchsuchen kann?

Mit etwas Suche habe ich dies gefunden.

# systemctl --state=failed
  UNIT                         LOAD   ACTIVE SUB    DESCRIPTION
●systemd-modules-load.service loaded failed failed Load Kernel Modules

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

1 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

# systemctl status systemd-modules-load.service 
● systemd-modules-load.service - Load Kernel Modules
   Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static)
   Active: failed (Result: exit-code) since Di 2014-07-29 11:58:19 CEST; 11min ago
     Docs: man:systemd-modules-load.service(8)
           man:modules-load.d(5)
  Process: 137 ExecStart=/usr/lib/systemd/systemd-modules-load (code=exited, status=1/FAILURE)
 Main PID: 137 (code=exited, status=1/FAILURE)

journalctl -b liefert keine Hinweise.

Mit dem heutigen Update kam ein neuer Kernel. Hat vielleicht damit was zu tun.
Wie bekomme ich heraus was hier genau nicht stimmt?
Ich vermute mal ein Problem mit den Virtualbox Modulen. Mir geht es jedoch um die Vorgehensweise bei solchen Problemen, damit ich nicht immer wieder hier Fragen muss.

# grep 2014-07-29 /var/log/pacman.log 
[2014-07-29 11:35] [PACMAN] Running 'pacman -Syu'
[2014-07-29 11:35] [PACMAN] synchronizing package lists
[2014-07-29 11:35] [PACMAN] starting full system upgrade
[2014-07-29 11:36] [ALPM-SCRIPTLET] >>> Updating module dependencies. Please wait ...
[2014-07-29 11:36] [ALPM-SCRIPTLET] >>> Generating initial ramdisk, using mkinitcpio.  Please wait...
[2014-07-29 11:36] [ALPM-SCRIPTLET] ==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'default'
[2014-07-29 11:36] [ALPM-SCRIPTLET]   -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img
[2014-07-29 11:36] [ALPM-SCRIPTLET] ==> Starting build: 3.15.7-1-ARCH
[2014-07-29 11:36] [ALPM-SCRIPTLET]   -> Running build hook: [base]
[2014-07-29 11:36] [ALPM-SCRIPTLET]   -> Running build hook: [udev]
[2014-07-29 11:36] [ALPM-SCRIPTLET]   -> Running build hook: [autodetect]
[2014-07-29 11:36] [ALPM-SCRIPTLET]   -> Running build hook: [modconf]
[2014-07-29 11:36] [ALPM-SCRIPTLET]   -> Running build hook: [block]
[2014-07-29 11:36] [ALPM-SCRIPTLET]   -> Running build hook: [filesystems]
[2014-07-29 11:36] [ALPM-SCRIPTLET]   -> Running build hook: [keyboard]
[2014-07-29 11:36] [ALPM-SCRIPTLET]   -> Running build hook: [fsck]
[2014-07-29 11:36] [ALPM-SCRIPTLET] ==> Generating module dependencies
[2014-07-29 11:36] [ALPM-SCRIPTLET] ==> Creating gzip initcpio image: /boot/initramfs-linux.img
[2014-07-29 11:36] [ALPM-SCRIPTLET] ==> Image generation successful
[2014-07-29 11:36] [ALPM-SCRIPTLET] ==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'fallback'
[2014-07-29 11:36] [ALPM-SCRIPTLET]   -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-fallback.img -S autodetect
[2014-07-29 11:36] [ALPM-SCRIPTLET] ==> Starting build: 3.15.7-1-ARCH
[2014-07-29 11:36] [ALPM-SCRIPTLET]   -> Running build hook: [base]
[2014-07-29 11:36] [ALPM-SCRIPTLET]   -> Running build hook: [udev]
[2014-07-29 11:36] [ALPM-SCRIPTLET]   -> Running build hook: [modconf]
[2014-07-29 11:36] [ALPM-SCRIPTLET]   -> Running build hook: [block]
[2014-07-29 11:36] [ALPM-SCRIPTLET] ==> WARNING: Possibly missing firmware for module: aic94xx
[2014-07-29 11:36] [ALPM-SCRIPTLET] ==> WARNING: Possibly missing firmware for module: smsmdtv
[2014-07-29 11:36] [ALPM-SCRIPTLET]   -> Running build hook: [filesystems]
[2014-07-29 11:36] [ALPM-SCRIPTLET]   -> Running build hook: [keyboard]
[2014-07-29 11:36] [ALPM-SCRIPTLET]   -> Running build hook: [fsck]
[2014-07-29 11:36] [ALPM-SCRIPTLET] ==> Generating module dependencies
[2014-07-29 11:36] [ALPM-SCRIPTLET] ==> Creating gzip initcpio image: /boot/initramfs-linux-fallback.img
[2014-07-29 11:36] [ALPM-SCRIPTLET] ==> Image generation successful
[2014-07-29 11:36] [PACMAN] upgraded linux (3.15.5-2 -> 3.15.7-1)
[2014-07-29 11:36] [PACMAN] upgraded linux-headers (3.15.5-2 -> 3.15.7-1)
[2014-07-29 11:36] [PACMAN] Running 'pacman -Scc'

Gruß

[gelöscht]

https://wiki.archlinux.org/index.php/Systemd#Troubleshooting

cipher

Danke für den Hinweis.

Jedoch liefert journalctl -b, wie schon geschrieben, keine Ausgabe.

# systemctl status systemd-modules-load.service 
● systemd-modules-load.service - Load Kernel Modules
   Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static)
   Active: failed (Result: exit-code) since Di 2014-07-29 13:14:38 CEST; 5s ago
     Docs: man:systemd-modules-load.service(8)
           man:modules-load.d(5)
  Process: 1426 ExecStart=/usr/lib/systemd/systemd-modules-load (code=exited, status=1/FAILURE)
 Main PID: 1426 (code=exited, status=1/FAILURE)

# journalctl -b _PID=1426
-- Logs begin at Mi 2014-07-23 10:04:28 CEST, end at Di 2014-07-29 11:58:38 CEST

yannsen

cipher schrieb
# journalctl -b _PID=1426

Trotz '#': Hast du auch wirklich root-Rechte? Ich habe das mal kurz nachgespielt und bei kommt nur was wenn ich es mit root-Rechten ausführe.

cipher

yannsen schriebTrotz '#': Hast du auch wirklich root-Rechte? Ich habe das mal kurz nachgespielt und bei kommt nur was wenn ich es mit root-Rechten ausführe.

Hmm, OK du hast Recht.
Ich habe journalctl die ganze Zeit immer mit Benutzerrechten ausgeführt. Da er nie gemeckert hat habe ich das auch nicht in Erwägung gezogen. Danke für den Tip.
Das Raute-Zeichen mache ich normalerweise händisch davor damit erkennbar ist was die Eingabe war und was die Ausgabe.

Hier also die Ausgabe:

# journalctl -b _PID=951
-- Logs begin at Di 2014-07-15 15:26:15 CEST, end at Di 2014-07-29 17:48:23 CEST. --
Jul 29 17:47:29 t420s systemd-modules-load[951]: Failed to insert 'vboxdrv': Exec format error
Jul 29 17:47:29 t420s systemd-modules-load[951]: Failed to insert 'vboxnetadp': Exec format error
Jul 29 17:47:29 t420s systemd-modules-load[951]: Failed to insert 'vboxnetflt': Exec format error
Jul 29 17:47:29 t420s systemd-modules-load[951]: Failed to insert 'vboxpci': Exec format error
Jul 29 17:47:29 t420s systemd-modules-load[951]: Failed to insert 'acpi_call': Exec format error
Jul 29 17:47:29 t420s systemd-modules-load[951]: Failed to insert 'tp_smapi': Exec format error

Mit Virtualbox lag ich ja gar nicht soweit entfernt.
Denke mit dem nächsten Update werden die Fehler weg sein.

Aber mir ging es ja eigentlich um die Vorgehensweise bei einem solchen Problem. Ich stehe da immer etwas auf dem Schlauch und weis nicht wo ich nachschauen muss um weitere Informationen zu bekommen. Durch die Systemd Umstellung hat sich ja einiges geändert, und ich blicke da noch nicht so ganz durch.

Da wäre nur noch die Möglichkeit der Umlenkung der Bootausgabe.
Geht das nicht?
Das würde mir als erste Anlaufstelle bei der Fehlersuche sehr weiterhelfen.

Gruß

yannsen

cipher schrieb Das Raute-Zeichen mache ich normalerweise händisch davor damit erkennbar ist was die Eingabe war und was die Ausgabe.

Das finde ich an der Stelle schlecht. $ für den normalen User, # für root. So bin ich das von der Bash gewöhnt.

cipher schrieb Aber mir ging es ja eigentlich um die Vorgehensweise bei einem solchen Problem. Ich stehe da immer etwas auf dem Schlauch und weis nicht wo ich nachschauen muss um weitere Informationen zu bekommen. Durch die Systemd Umstellung hat sich ja einiges geändert, und ich blicke da noch nicht so ganz durch.

Wo ist jetzt dein Problem, du siehst doch die Fehlermeldungen. Ich würde mal darauf tippen, dass du ein Update bei einem Mirror gemacht hast, der noch nicht 100% aktuell war und du schon einen neuen Kernel drauf hast die restlichen Pakete aber noch nicht gepasst haben. Das gleiche Problem hatte ich mit dem aktuellen Kernel und VirtualBox auch.

cipher

yannsen schriebDas finde ich an der Stelle schlecht. $ für den normalen User, # für root. So bin ich das von der Bash gewöhnt.

OK, das klingt logisch. Werde mich in Zukunft daran halten.

yannsen schriebWo ist jetzt dein Problem, du siehst doch die Fehlermeldungen. Ich würde mal darauf tippen, dass du ein Update bei einem Mirror gemacht hast, der noch nicht 100% aktuell war und du schon einen neuen Kernel drauf hast die restlichen Pakete aber noch nicht gepasst haben. Das gleiche Problem hatte ich mit dem aktuellen Kernel und VirtualBox auch.

Das Problem ist, ich wusste nicht wo ich suchen muss um dem Problem auf die Spur zu kommen. Klar ist das Problem damit gelöst, vielen Dank auch für deine Hilfe. Das Problem ist ja auch schon behoben.

Wie schon geschrieben ging es mir um die generelle Vorgehensweise unter Systemd bei fehlern. Das aktuelle Problem sollte als Beispiel dienen.

[gelöscht]

Umleiten auf einer log.txt funktioniert auch ist nur sinnlos (journalctl -b > /home/$USER/log.txt)
Wenn das hier gelöst ist bitte auch als gelöst makieren, vielen Dank.

cipher

pitt schriebUmleiten auf einer log.txt funktioniert auch ist nur sinnlos (journalctl -b > /home/$USER/log.txt)
Wenn das hier gelöst ist bitte auch als gelöst makieren, vielen Dank.

Mir geht es nicht um die Ausgabe von journalctl (das macht keinen Sinn), sondern um die Ausgabe des Bootvorganges.

Meine Frage war, ist es möglich die Ausgabe des Bootvorganges in eine Datei umzuleiten? Es wäre hilfreich eine Datei zu haben die 1:1 das wiedergibt was beim hochfahren in TTY1 steht.

midixinga

https://wiki.archlinux.org/index.php/Boot_Debugging
https://wiki.archlinux.org/index.php/Journalctl#Diagnosing_boot_problems

Ansonsten:

journalctl -b

zeigt alle vom journald erfassten Medlungen an; wenn du nur die kernel-meldungen haben willst

dmesg -T

; aber afaik ist das nur eine Teilmenge von

journalctl -b

Was vermisst Du denn im Journal ?

cipher

midixinga schriebhttps://wiki.archlinux.org/index.php/Boot_Debugging
https://wiki.archlinux.org/index.php/Journalctl#Diagnosing_boot_problems

Ansonsten:
journalctl -b
zeigt alle vom journald erfassten Medlungen an; wenn du nur die kernel-meldungen haben willst
dmesg -T
; aber afaik ist das nur eine Teilmenge von
journalctl -b
Was vermisst Du denn im Journal ?

Danke für die Links. Leider ist mein Englisch Bescheiden.

Ich vermisse nichts im journal. Es sind mir zu viele Informationen die ich dann ausfiltern muss. Ich weis ja noch nicht wonach ich suchen muss.
Beim Bootvorgang habe ich den Fehler schon lokalisiert, kann ihn aber nicht mehr sehen da er weg ist.

Ich hatte mir gedacht wenn ich die Ausgabe des Bootvorgang irgendwo zwischenspeichere, kann ich auf diese Information zurückgreifen. Man kann hier schön erkennen wo es klemmt. Dann kann ich immer noch mit journalctl bzw systemctl dem Problem auf den Grund gehen.