Raspi 4 reboot funktioniert nicht

[SouzA]

Hallo liebe fhem-Gemeinde,

ich habe das Problem, dass mein Raspi 4 nicht mehr auf sudo reboot hört.
Wenn ich den Befehl über putty eingebe, dann fährt der Raspi vermeintlich runter (ssh wird getrennt und fhem ist nicht mehr erreichbar), bleibt aber mit einer dauergrünen LED stehen und startet nicht neu.
Dann muss der Strom ab, neu dran und er läuft wieder hoch.

Der Befehl sudo shutdown funktioniert.
Raspi4 mit Bullseye auf SSD.

Wo kann ich da anfangen den Fehler zu suchen?

Vielen Dank für Unterstützung.
Bis denn
SouzA

[yersinia]

Steht was im log?

Ansonsten kann shutdown auch neustarten:

Code Auswählen Erweitern

sudo shutdown -r now
https://linux.die.net/man/8/shutdown

[schnulli]

Problem hatte ich auch mal. Was passiert wenn Du "sudo su" und danach "reboot" eingibst? Hast die Möglichkeit einen Monitor anzuschliessen?

Grüße

Chris

[SouzA]

Steht was im log?

Hi,
Vielen Dank für deine Antwort.
Da hast du meine Probleme direkt auf den Punkt gebracht.
Welcher log und wie rufe ich den auf? 

Ansonsten werde ich mir deinen Link auch noch anschauen. Vielen Dank dafür.

Bis denn
SouzA

[yersinia]

Welcher log und wie rufe ich den auf? 

dmesg geht immer aber schlecht zu lesen (ohne grep oder tails etc.) - ansonsten unter systemd auch journalctl.

[Otto123]

bleibt aber mit einer dauergrünen LED stehen

Bedeutet er greift weiter auf die SSD zu. Die ist entweder kaputt oder das System klemmt in diesem Zustand fest.
Unbedingt Monitor anschließen und zuschauen was da passiert.

[SouzA]

Hallo liebe Leute und vielen Dank für die Unterstützung.

Das mit dem Monitor habe ich jetzt noch nicht geschafft. Kommt noch.

Unten aber mal der journalctl.
Um 18:57:00 sudo reboot über ssh gemacht.
Dann hat der Pi wieder gehangen.
Gegen 18:58:30 Steckdose aus.
Um ca. 18:59 Steckdose ein.

Der log hört aber mittendrin weit vor 18:58 auf.
Ich seh aus dem Ding nix. Ihr?
Ich kann leider nicht alles von dem Vorgang posten, weil das irgendwann mittendrin vom Forum abgeschnitten wird.

Wie schon gesagt, mache ich nachher den Monitor-Test mal.

Thx und bis denn
SouzA

Code Auswählen Erweitern


Dez 12 18:57:25 fhemRasPi4 avahi-daemon[498]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.178.47.
Dez 12 18:57:25 fhemRasPi4 avahi-daemon[498]: New relevant interface eth0.IPv4 for mDNS.
Dez 12 18:57:25 fhemRasPi4 avahi-daemon[498]: Registering new address record for 192.168.178.47 on eth0.IPv4.
Dez 12 18:57:25 fhemRasPi4 systemd[1]: Stopping Network Time Synchronization...
Dez 12 18:57:25 fhemRasPi4 systemd[1]: systemd-timesyncd.service: Succeeded.
Dez 12 18:57:25 fhemRasPi4 systemd[1]: Stopped Network Time Synchronization.
Dez 12 18:57:25 fhemRasPi4 systemd[1]: Starting Network Time Synchronization...
Dez 12 18:57:25 fhemRasPi4 systemd[1]: Started Network Time Synchronization.
Dez 12 18:57:25 fhemRasPi4 dhcpcd[509]: forked to background, child pid 736
Dez 12 18:57:25 fhemRasPi4 dhcpcd[509]: forked to background, child pid 736
Dez 12 18:57:25 fhemRasPi4 systemd[1]: Started DHCP Client Daemon.
Dez 12 18:57:25 fhemRasPi4 systemd[1]: Reached target Multi-User System.
Dez 12 18:57:25 fhemRasPi4 systemd[1]: Reached target Graphical Interface.
Dez 12 18:57:25 fhemRasPi4 systemd[1]: Starting Update UTMP about System Runlevel Changes...
Dez 12 18:57:25 fhemRasPi4 systemd[1]: systemd-update-utmp-runlevel.service: Succeeded.
Dez 12 18:57:25 fhemRasPi4 systemd[1]: Finished Update UTMP about System Runlevel Changes.
Dez 12 18:57:25 fhemRasPi4 systemd[1]: Startup finished in 3.863s (kernel) + 15.916s (userspace) = 19.779s.
Dez 12 18:59:31 fhemRasPi4 systemd-timesyncd[734]: Initial synchronization to time server 194.36.144.87:123 (0.debian.pool.ntp.org).
Dez 12 18:59:41 fhemRasPi4 sshd[678]: Accepted password for pi from 192.168.178.10 port 55160 ssh2
Dez 12 18:59:41 fhemRasPi4 sshd[678]: pam_unix(sshd:session): session opened for user pi(uid=1000) by (uid=0)
Dez 12 18:59:41 fhemRasPi4 systemd[1]: Created slice User Slice of UID 1000.
Dez 12 18:59:41 fhemRasPi4 systemd[1]: Starting User Runtime Directory /run/user/1000...
Dez 12 18:59:41 fhemRasPi4 systemd-logind[532]: New session 1 of user pi.
Dez 12 18:59:41 fhemRasPi4 systemd[1]: Finished User Runtime Directory /run/user/1000.
Dez 12 18:59:41 fhemRasPi4 systemd[1]: Starting User Manager for UID 1000...
Dez 12 18:59:41 fhemRasPi4 systemd[746]: pam_unix(systemd-user:session): session opened for user pi(uid=1000) by (uid=0)
Dez 12 18:59:42 fhemRasPi4 systemd[751]: gpgconf: Fehler bei Ausführung von `/usr/lib/gnupg/scdaemon': wahrscheinlich nicht installiert
Dez 12 18:59:42 fhemRasPi4 systemd[746]: Queued start job for default target Main User Target.
Dez 12 18:59:42 fhemRasPi4 systemd[746]: Created slice User Application Slice.
Dez 12 18:59:42 fhemRasPi4 systemd[746]: Reached target Paths.
Dez 12 18:59:42 fhemRasPi4 systemd[746]: Reached target Timers.
Dez 12 18:59:42 fhemRasPi4 systemd[746]: Listening on GnuPG network certificate management daemon.
Dez 12 18:59:42 fhemRasPi4 systemd[746]: Listening on GnuPG cryptographic agent and passphrase cache (access for web browsers).
Dez 12 18:59:42 fhemRasPi4 systemd[746]: Listening on GnuPG cryptographic agent and passphrase cache (restricted).
Dez 12 18:59:42 fhemRasPi4 systemd[746]: Listening on GnuPG cryptographic agent (ssh-agent emulation).
Dez 12 18:59:42 fhemRasPi4 systemd[746]: Listening on GnuPG cryptographic agent and passphrase cache.
Dez 12 18:59:42 fhemRasPi4 systemd[746]: Reached target Sockets.
Dez 12 18:59:42 fhemRasPi4 systemd[746]: Reached target Basic System.
Dez 12 18:59:42 fhemRasPi4 systemd[746]: Reached target Main User Target.


[yersinia]

Wann hattest du den letzten Neustart via reboot versucht? Interessant wäre der Log vor dem Neustart. Alle boots kannst du mit

Code Auswählen Erweitern

journalctl --list-boots
herausfinden, wahrscheinlich ist -1 (der boot vor dem aktuellen).

Wenn du dann eine (ungefähre) Uhrzeit hast, kannst du dies weiter eingrenzen:

Code Auswählen Erweitern

journalctl --boot -1 --since "2021-12-12 18:00:00"

Kurios ist aber wenn unter gleichen Bedingungen reboot nicht sauber funktioniert aber (Annahme) shutdown -r now schon!?

[Otto123]

Gegen 18:58:30 Steckdose aus.
Um ca. 18:59 Steckdose ein.

Meint: Du hast hart aus geschaltet? Nur 1,5 min warten ist leicht nervös, je nach dem was auf der Kiste läuft kann das auch mal dauern.

Das mit den Zeiten im Log ist wegen der fehlenden Hardware Uhr sehr trügerisch. Die Auschalt und startzeit ist damit ein scheinbar nahtloser Übergang, der Zeit Sprung kommt:

Dez 12 18:59:31 fhemRasPi4 systemd-timesyncd[734]: Initial synchronization to time server 194.36.144.87:123 (0.debian.pool.ntp.org).

[SouzA]

Tja Leute, was soll ich sagen?!

Nachdem ich den Pi jetzt mal anderer Stelle (wegen Pi zum Monitor ist einfacher als anders rum) rebootet hab, rebootet der jetzt auch wieder an ursprünglicher Stelle normal!?
Muß ich nicht verstehen, oder?

Ich versuche nachher noch nen paar reboots und versuche mal aus den alten logs schlau zu werden.

Bis hierher bedanke ich mich recht herzlich und ich melde mich wieder.

Thx und bis denn
SouzA

[Otto123]

klingt z.B. nach irgendwas ist/war kaputt (Filesystem / Datenbank) und wurde beim reboot versucht zu reparieren. Einfach ausschalten hat den Zustand nicht verbessert. Irgendwann war es wieder gut. Das wäre die günstige aller Annahmen.

[betateilchen]

Klingt für mich nach einem Filesystem mit Journal, das nach 1,5 Minuten einfach noch nicht mit der eigenen Aktualisierung fertig war und dadurch den Restart verzögert hat.

Wenn das Problem nochmal auftritt, warte mal mindestens 5 Minute.

[SouzA]

Klingt für mich nach einem Filesystem mit Journal, das nach 1,5 Minuten einfach noch nicht mit der eigenen Aktualisierung fertig war und dadurch den Restart verzögert hat.

Wenn das Problem nochmal auftritt, warte mal mindestens 5 Minute.

Ok, werde ich machen.

Nochmals vielen Dank für die vielen guten und schnellen Tips!

Ich kann es jetzt aber nicht mehr reproduzieren...
Vielleicht bleibt es ja auch tatsächlich dabei. Mal schauen.

Thx und bis denn
SouzA

[Wernieman]

Und mal unabhängig vom Pi .. ein Boot kann auch mal länger dauern .. also 5 Minuten sind im (bekannten) Problemfalle dann auch zu wenig ... mindestens 10 Minuten bei einem Headless-System sind mein Erfahrungswert.

[betateilchen]

mindestens 10 Minuten bei einem Headless-System sind mein Erfahrungswert.

so lange braucht nichtmal mein Pi4, der komplett ohne eigenen Datenträger direkt vom Netzwerk und per NFS bootet