Update nach Reboot wieder zurückgesetzt

Hallo zusammen,

habe ein ähnliches Problem wie hier https://discourse.pi-hole.net/t/upgrade-is-lost-after-reboot/51161 beschrieben, nur leider wurde damals keine Lösung gefunden.

Die angebotenen Updates werden scheinbar korrekt ausgeführt und die aktualisierten Versionen auch im Dashboard angezeigt. Funktion von Pi-Hole scheint auch einwandfrei gegeben. Nach einem Reboot ist jedoch wieder alles auf den alten Versionsständen (siehe unten).

Ich befürchte es hat irgendeine Datenbank gecrasht, nur leider kann ich mit dem Debug-Log nicht viel anfangen. Wäre sehr an einer Lösung interessiert, nur leider bin ich in Linux nicht wirklich bewandert. Wäre super, wenn mir jemand weiterhelfen könnte.

Debug Log nach Update auf Pi-hole v5.10 FTL v5.15 Web Interface v5.12
https://tricorder.pi-hole.net/seeEPlN3/

Debug Log nach Reboot und damit zurück auf Pi-hole v5.9.1 FTL v5.14 Web Interface v5.11
https://tricorder.pi-hole.net/tbkux8x4/

Das ist echt spannend.
Vor dem Reboot

[i] 2022-05-30:18:39:54 debug log has been initialized.
*** [ DIAGNOSING ]: Core version
[i] Core: v5.10 (https://discourse.pi-hole.net/t/how-do-i-update-pi-hole/249)
[i] Remotes: origin	https://github.com/pi-hole/pi-hole.git (fetch)
             origin	https://github.com/pi-hole/pi-hole.git (push)
[i] Branch: master
[i] Commit: v5.10-0-g853f6b7d

*** [ DIAGNOSING ]: Web version
[i] Web: v5.12 (https://discourse.pi-hole.net/t/how-do-i-update-pi-hole/249)
[i] Remotes: origin	https://github.com/pi-hole/AdminLTE.git (fetch)
             origin	https://github.com/pi-hole/AdminLTE.git (push)
[i] Branch: master
[i] Commit: v5.12-0-g6c320a42

*** [ DIAGNOSING ]: FTL version
[✓] FTL: v5.15

   Last gravity run finished at: Mon May 30 18:29:53 CEST 2022

Hinterher

[i] 2022-05-30:18:48:17 debug log has been initialized.
*** [ DIAGNOSING ]: Core version
[i] Core: v5.9.1 (https://discourse.pi-hole.net/t/how-do-i-update-pi-hole/249)
[i] Remotes: origin	https://github.com/pi-hole/pi-hole.git (fetch)
             origin	https://github.com/pi-hole/pi-hole.git (push)
[i] Branch: master
[i] Commit: v5.9.1-0-g326cd6a

*** [ DIAGNOSING ]: Web version
[i] Web: v5.11 (https://discourse.pi-hole.net/t/how-do-i-update-pi-hole/249)
[i] Remotes: origin	https://github.com/pi-hole/AdminLTE.git (fetch)
             origin	https://github.com/pi-hole/AdminLTE.git (push)
[i] Branch: master
[i] Commit: v5.11-0-g64bbce90

*** [ DIAGNOSING ]: FTL version
[✓] FTL: v5.14 (https://discourse.pi-hole.net/t/how-do-i-update-pi-hole/249)

   Last gravity run finished at: Sun May 22 03:24:19 CEST 2022

[2022-05-24 15:17:13.041 672/T674] Listening on port 4711 for incoming IPv6 telnet connections
   [2022-05-24 15:17:13.042 672/T675] Listening on Unix socket
   [2022-05-24 15:17:13.044 672M] Reloading DNS cache
   [2022-05-24 15:17:16.841 672/T676] Compiled 6 whitelist and 0 blacklist regex filters for 104 clients in 2790.1 msec
   [2022-05-24 15:17:26.857 672M] Blocking status is enabled
   [2022-05-30 18:44:08.243 672M] WARN: Found database entries in the future (2022-05-30 18:45:00 (1653929100), last timestamp for importing: 2022-05-24 15:55:00 (1653400500)). Your over-time statistics may be incorrect (found in src/dnsmasq_interface.c:671)
   [2022-05-30 18:44:08.650 672/T678] Resizing "FTL-strings" from 81920 to (122880 * 1) == 122880 (/dev/shm: 1.9MB used, 2.0GB total, FTL uses 1.9MB)
   [2022-05-30 18:45:06.826 672/T676] Notice: Database size is 749.82 MB, deleted 116142 rows

Dies ist ein Problem außerhalb von Pi-hole. Es scheint, als sei dein System zu einem früheren Zeitpunkt zurückgekehrt - hast du ein System, welches automatisch Snapshots anlegt?
Es sind nicht nur die Pi-hole Versionen wieder auf dem alten Stand, sondern auch die Gravity Datenbank. Auch das Log wird am 24.05. fortgeführt, springt dann aber auf dem 30.05.

Also so etwas wie snapshots habe ich nicht bewusst eingerichtet. Bisher funktionierte das Update auch immer problemlos und blieb auch nach einem reboot bestehen.

Gibts denn sonst noch Ideen, auch was ich evtl zur Fehleranalyse tun kann? Vielen Dank!

Das liest sich so, als wäre das Dateisystem nur mit Lesezugriff eingehängt.

Das Betriebssystem würde Nur-Lese-Zugriff z.B. dann veranlassen, wenn es Dateisystemfehler bei Betriebssystem-Dateien erkannt hat.

Ausgeführt auf dem Pi-hole-Rechner, was gibt folgendes Kommando zurück:

 mount | grep '(ro'

Daran hatte ich auch schon gedacht, aber vor dem Update keine Anzeichen dafür gesehen. Hier die Ausgabe:

root@raspberrypi:~# mount | grep '(ro'
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)

Schaut für mich erstmal i.O. aus, oder?

Ich würde als nächsten Step mal versuchen, ein aktuelles Backup auf eine neue SD einzuspielen und dann nochmal das Update durchführen, um auszuschließen, dass die SD Karte nicht mehr fit ist. Oder was meint ihr?

Thema erledigt: Das Update bleibt erhalten, sobald ich die neue SD-Karte mit dem eingespielten Backup-System nutze.

Scheint also tatsächlich ein SD-Karten Problem zu sein, dass sich vermutlich erst beim Updateversuch mit entsprechend vielen Schreib- und Lesezugriffen einstellt. Vielen Dank für die Hilfe!

2 Likes

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.