Raspberry bootet nicht mehr nach sudo poweroff

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Dieser Thread Umleitungen beim Update mit apt-get zeigt, dass vermutlich die alten Dateien nicht umbenannt, sondern verschoben werden.

    //Edit

    Karel Sieh mal bitte nach, ob es das Verzeichnis noch gibt und zeige uns mal die Ausgabe von ls -la /usr/share/rpikernelhack!

  • Früher hatten die noch eine andere Bedeutung, aber seit dem systemd genutzt wird, gibt es keine runlevel mehr, sondern targets. Die Runlevel werden weiterhin aus Gründen der Kompatibilität angeboten.

    poweroff und shutdown sind keine eigenen Programme, sondern nur Symlinks auf systemctl.

    Code
    root@nexus:/usr/sbin# ls -l | grep systemctl
    lrwxrwxrwx 1 root root        14 Sep 13 02:58 halt -> /bin/systemctl
    lrwxrwxrwx 1 root root        14 Sep 13 02:58 poweroff -> /bin/systemctl
    lrwxrwxrwx 1 root root        14 Sep 13 02:58 reboot -> /bin/systemctl
    lrwxrwxrwx 1 root root        14 Sep 13 02:58 runlevel -> /bin/systemctl
    lrwxrwxrwx 1 root root        14 Sep 13 02:58 shutdown -> /bin/systemctl
    lrwxrwxrwx 1 root root        14 Sep 13 02:58 telinit -> /bin/systemctl

    Wer es ganz genau wissen will, poweroff und shutdown machen exakt dasselbe:

    Beide Symlinks setzen arg_action auf ACTION_POWEROFF


    Das ist bei vielen Programmen unter Linux üblich, dass Symlinks auf ein Programm unterschiedliche Subkommandos unterstützen.

    Kann ja jeder selbst mal schauen, wie viel davon versteckt ist:

    Bash
    find /sbin/ -type l -printf "%p -> %l\n" | sort


    Ich habe auch den Verdacht, dass dieses "Kernel-Update-Script" möglicherweise diesen Vorgang nicht immer vollständig unterstützt. Diejenigen, die als erste solch ein Script (ungeahnt) nutzen, laufen Gefahr, dies als Beta-Nutzer zu tun.

    Beim Update des Pakets raspberrypi-kernel werden die Pfade mittels dpkg-divert nach /usr/share/rpikernelhack/ umgeleitet (preinst).

    Quelle: raspberrypi-firmware-nokernel_1.20180328-1~nokernel1.tar.gz

    Bash: debian/raspberrypi-kernel.preinst
    #!/bin/sh
    mkdir -p /usr/share/rpikernelhack/overlays
    mkdir -p /boot/overlays
    dpkg-divert --package rpikernelhack --divert /usr/share/rpikernelhack/bcm2708-rpi-0-w.dtb /boot/bcm2708-rpi-0-w.dtb
    dpkg-divert --package rpikernelhack --divert /usr/share/rpikernelhack/bcm2708-rpi-b-plus.dtb /boot/bcm2708-rpi-b-plus.dtb
    
    # ...

    Am Ende (postinst) werden die Dateien in /boot gelöscht und die Dateien aus /usr/share/rpikernelhack/ dort hineinkopiert.

    Dann gibt es noch das Paket raspberrypi-bootloader, welches genauso vorgeht.

    Das ursprüngliche Problem war, dass dpkg mit Hardlinks arbeitet und die boot-Partition FAT32 nutzen muss und das Dateisystem unterstützt das nicht.

    Der Hack ist ziemlich sicher, da beim Schreiben erst mal /boot nichts angefasst wird. Erst am Ende nach dem Entpacken werden die Dateien in /boot einzeln gelöscht, dann wird mittels dpkg-divert die Datei ins Ziel kopiert und es wird sogar nur kopiert, wenn die Datei nicht vorhanden ist. Dann wird noch ein sync nach jeden Vorgang gemacht. Wie man zu dem Problem kommt, dass auf einmal alle Dateien fehlen, kann ich nicht nachvollziehen, aber einzelne Dateien kann man mit sehr großer Wahrscheinlichkeit dann korrumpieren, wenn man gegen Ende der Installation apt-get einfach den Strom ausschaltet.

  • wenn man gegen Ende der Installation apt-get einfach den Strom ausschaltet.

    aber auch das ist nicht passiert. Wie gesagt, ich habe kein update bzw. upgrade gefahren. Lediglich das System heruntergefahren. Und zu früh den Stecker gezogen kann ich eigentlich auch ausschließen, ich bin da eher vorsichtig. Ich warte immer, bis alle Lämpchen aus sind....

  • Wie gesagt, ich habe kein update bzw. upgrade gefahren. Lediglich das System heruntergefahren.

    Hast Du dein System so konfiguriert, dass ein full-upgrade automatisch gemacht wird?

    BTW: Gute OSs sollte man _während_ eines laufenden upgrade, nicht ordnungsgemäß runterfahren können.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Nein. An der upgrade Konfiguration habe ich nicht herumgefummelt.

    OK, dann hast Du das upgrade absichtlich (manuell) gemacht und das was Du im Beitrag #24 geschrieben hast:

    Zitat

    Wie gesagt, ich habe kein update bzw. upgrade gefahren.

    stimmt nicht? Du hast das update/upgrade evtl. nicht unmittelbar vor dem Runterfahren des PI, gemacht, oder?

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Ach so meintest du das. Ich habe das System beim Aufsezten vor einer Woche zuerst mit

    Code
    sudo apt-get update
    sudo apt-get upgrade

    auf den neuesten Stand gebracht. Danach reboot. Und dann ca. 1 Woche später heruntergefahren und dann wars kaputt....

  • ... vor einer Woche zuerst mit

    auf den neuesten Stand gebracht. Danach reboot. Und dann ca. 1 Woche später heruntergefahren und dann wars kaputt....

    So, ... und in dieser 1 Woche, zwischen dem reboot und dem herunterfahren, muss etwas passiert sein, das dazu geführt hat, dass einige Dateien aus dem /boot-Verzeichnis "verschwunden" sind.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Das ist korrekt!

    Poste (im spoiler) mal die richtig/brauchbar anonymisierte Ausgabe von:

    Code
    last | head -n 45

    Den Wert für "-n" (hier 45 als Beispiel) so anpassen, dass der Zeitraum zwischen dem reboot (nach dem Aufsetzen vor einer Woche) und dem herunterfahren (siehe dein Beitrag #29) beinhaltet ist.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • sudo poweroff

    zu

    sudo shutdown -now

    Der erste funktioniert, der zweite gibt eine Fehlermeldung. Der - ist zuviel. Ohne - ist ja schon beantwortet.

    Übrigens ist mir eben aufgefallen, dass man shutdown bei auf deutsch eingestellter Oberfläche eine Übersetzung von 2003 ausgibt, noch schön mit Runleveln etc. Kann aber auch daran liegen, dass ich auf dem betreffenden RPi manpages-de nachinstalliert hatte.

    :rolleyes: sudo !!

  • Da steht ja nur meine interne IP von der ich auf den Raspi zugegriffen habe.

    OK, dann musst Du nicht anonymisieren.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • last | head -n 45

    Spoiler anzeigen

    reboot system boot 5.15.84-v8+ Thu Jan 1 01:00 still running

    pi pts/1 10.146.26.158 Sat Jan 21 08:26 - 08:26 (00:00)

    pi pts/1 10.146.26.158 Fri Jan 20 22:36 - 22:41 (00:05)

    pi pts/1 10.146.26.158 Sun Jan 15 22:23 - 22:24 (00:00)

    pi pts/1 10.146.26.158 Sun Jan 15 20:44 - 21:52 (01:08)

    pi pts/1 10.146.26.158 Sun Jan 15 20:15 - 20:43 (00:28)

    pi pts/1 10.146.26.158 Sat Jan 14 22:53 - 23:16 (00:23)

    reboot system boot 5.15.84-v8+ Thu Jan 1 01:00 - 08:26 (19378+07:26)

    pi pts/1 10.146.26.158 Sat Jan 14 22:49 - 22:49 (00:00)

    pi pts/1 10.146.26.158 Sat Jan 14 12:57 - 14:08 (01:10)

    pi pts/1 10.146.26.158 Sat Jan 14 11:52 - 12:17 (00:25)

    reboot system boot 5.15.84-v8+ Thu Jan 1 01:00 - 22:50 (19371+21:50)

    pi pts/0 10.146.26.158 Sat Jan 14 11:43 - 11:49 (00:06)

    reboot system boot 5.15.84-v8+ Thu Jan 1 01:00 - 11:51 (19371+10:51)

    pi pts/0 10.146.26.158 Sat Jan 14 11:26 - 11:41 (00:14)

    reboot system boot 5.15.84-v8+ Thu Jan 1 01:00 - 11:41 (19371+10:41)

    pi pts/0 10.146.26.158 Sat Jan 14 11:09 - 11:09 (00:00)

    reboot system boot 5.15.84-v8+ Thu Jan 1 01:00 - 11:09 (19371+10:09)

    pi pts/0 10.146.26.158 Sat Jan 14 11:04 - 11:06 (00:01)

    pi pts/0 10.146.26.171 Sat Jan 14 07:00 - 07:02 (00:02)

    pi pts/0 10.146.26.158 Fri Jan 13 22:32 - 22:32 (00:00)

    pi pts/0 10.146.26.158 Tue Jan 10 22:03 - 23:28 (01:24)

    reboot system boot 5.15.84-v8+ Thu Jan 1 01:00 - 11:06 (19371+10:06)

    pi pts/0 10.146.26.158 Tue Jan 10 20:56 - 22:02 (01:06)

    pi pts/0 192.168.10.2 Tue Jan 10 07:36 - 12:22 (04:45)

    pi pts/0 192.168.10.2 Tue Jan 10 07:33 - 07:36 (00:03)

    reboot system boot 5.15.84-v8+ Thu Jan 1 01:00 - 22:02 (19367+21:02)

    pi pts/0 192.168.10.2 Tue Jan 10 07:24 - 07:33 (00:08)

    reboot system boot 5.15.84-v8+ Thu Jan 1 01:00 - 07:33 (19367+06:33)

    pi pts/0 192.168.10.2 Tue Jan 10 07:13 - 07:19 (00:06)

    pi pts/0 10.146.26.158 Tue Jan 10 05:40 - 05:40 (00:00)

    reboot system boot 5.15.61-v8+ Thu Jan 1 01:00 - 07:19 (19367+06:19)

    pi pts/0 10.146.26.158 Tue Jan 10 05:33 - 05:34 (00:00)

    reboot system boot 5.15.61-v8+ Thu Jan 1 01:00 - 05:34 (19367+04:34)

    wtmp begins Thu Jan 1 01:00:02 1970

    Das dürfte passen. Wenn ich n-200 eingebe wird es nicht mehr länger, daher denke ich, dass der Startpunkt auch der Zeitpunkt des Aufsetzens war. Sa, 21., 8 Uhr irgendwas passt aber definitiv. Da ich ich das Teil ausgeschaltet und dann war der Fehler da.

  • ..., daher denke ich, dass der Startpunkt auch der Zeitpunkt des Aufsetzens war. Sa, 21., 8 Uhr irgendwas passt aber definitiv.

    Schau mal in den Logs nach, wann genau Du das update/upgrade (mit Kernel) gemacht hast.

    Wann war der shutdown, nach dem der PI nicht mehr booten konnte?

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!