Eure Sorgen möchte ich in Zeiten wie diesen haben ...

Selbst wenn es thumpdown gäbe, würde ich den nicht setzen - obwohl IMHO der eine oder andere Beitrag in diesem Thread das verdient hätte.

backup im Rescue Loader, Newnigma2 hat ein eigenes Backup Tool im Image, Merlin hat vor kurzem ein Plugin released und im GP4 findet man auch ein backup Tool und wem das alles zu einfach ist kann selbst ein backup im Terminal bei laufenden Image erstellen - per shell script oder einzelnen commands ...

Ergo gibt es für alle auf OE2.5(6) basierendes Images eine Lösung die hier bzw. in den entsprechenden Boards supported werden

lasst doch mal die Open* Tools wo sie hingehören ....

Wozu das Risiko eingehen? Ich sehe keinen Vorteil. Die DM9xx verwendet ext4 und kein ubifs. Wenn überhaupt, macht das Tool für die dm800SE/dm7020hd Sinn (ubifs)

Selbst wenn der Rescue Loader einer DM9xx defekt ist und das Web Interface nicht mehr erreichbar ist kann man den kernel über die command line im rescue mode flashen und das roofs manuell extrahieren und wenn man mutig ist mit mkfs.ext4 vorher eine neues Dateisystem anlegen. Im worst case kann kann man im CFE bios den rescue loader von USB starten und dann (über das WebIF) flashen.

Ich würde bei der DM9xx die Finger davon lassen

Sorry für das off Topic - Multiboot gehört nicht in diesen Threat.

Mein Tipp war nur, ohne Multibook vom Flash bzw. in den Rescue Loader zu booten um etwaige Probleme mit Barry Allen auszuschließen. Wie es ausieht, wurde /data in einem gebooteten BA Image formatiert

Wird /data im Rescue Mode gemountet oder nicht?

entweder mal das flashimage booten oder ein flashbackup erstellen, neu flashen ohne settings restore und ohne Barry Allen booten - also ohne SD Karte

Jedenfalls ganz ohne BA - der steckt überall seine Nase ungefragt rein

alternativ in den Rescue Loader ohne SD Karte booten und dann im rescue loader /dev/mmcblk0p2 nochmal formatieren

das Label dreambox-data und die ursprüngliche UUID würde ich beim mkfs.ext4 command mitgeben und dann gleich versuchen zu mounten

btw: mit der dm7080hd kann man auch ohne BA multibooten ohne das Device wechseln - wenn man weiß wie
warum man das auch in Zeiten wie diesen noch braucht ...

Sarkasmusresisdent also auch noch?

Du gehörst wohl auch zu jenen die bei einem Witz dreimal lachen: Das erste Mal wenn man ihn dir erzählt, das zweite Mal wenn man ihn dir erklärt und das dritte Mal wen du ihn verstehst. ...

Ja, bei diesem Unsinn gehen einem wirklich die Argumente aus - übrig bleibt nur noch fassungsloses Staunen ...

Alternative Wahrheiten, Desinformationen, zweifelhafte Propaganda und Polemik scheinen derzeit groß in Mode zu sein und machen augenscheinlich nirgends halt.

Trefft euch doch irgendwo im nirgendwo bei einer Sommerparty wo ihr keinen Schaden an der Allgemeinheit anrichten könnt und haut euch gegenseitig die Schädel ein, nachdem euch die Argumente und obskuren Ideen ausgegangen sind. Den Rest besorgt dann schon die Evolution ...

sonst mal per telnet oder ssh verbinden und die Ausgabe folgenden Befehles posten:

grep _path /etc/enigma2/settings

so sieht man, was alles eingestellt ist

einfach mit F5 (browsersuche) nach "second" suchen ...

flashable firmware images for dm500hd

flashable firmware images for dm800

wie aus einem abgedrehten SourceForge Thread kopiert ...

/dev hat immer 1970-01-01 - auch nach stundenlangem Betrieb

enigma2 schreibt ständig nach /proc/stb/fp - deshalb ändert sich die ctime laufend - das ist bei /dev nicht so.

die ctime von /proc/stb/fp wird beim reboot oder stromlos machen auf 1.1.1970 zurückgesetzt weil das proc filesystem neu erstellt wird und dann beim 1. Schreibvorgang durch enigma2 ausgelöst wieder aktualisiert wird. Vermutlich wird die ctime nicht verändert, wenn die Zeit beim Schreibvorgang vor der cdtime liegt. Nachdem booten aus dem deepstandby entspricht die ctime der Zeit des letzten Schreibvorganges vor dem shutdown, ist also nicht von 1970, solange die Box vor dem shutdown sich mind 1x die aktuelle Zeit geholt hat.

man könnte auch die ctime von /proc/net/dev verwenden, weil in die Datei ständig aktualisiert wird. Auch bei traffic über das loopback interface (lo) - also auch dann, wenn die box nicht im Netzwerk hängt

zu welchem Zeitpunkt liest du ctime von /etc aus?

Das kann ich leider nicht bestätigen, der Ordner /etc hat hier immer eine aktuelle Zeit, also nie das Jahr 1970 - egal ob nach reboot, aus standby oder nach stromlosen Zustand - immer über die rc.local automatisch beim boot ausgelesen, sogar mehrmals nach reboot und stromlosem Zustand

Wie es aussieht, bleibt die letzte ctime von /etc erhalten, wird aber dann irgendwann beim bootup überschrieben

nach /tmp/etc wurde die ctime von /etc über die rc.local geschrieben, der 2. command etwas später manuell. Beides nach stromlosen Zustand ausgeführt

root@dm900:~# cat /tmp/etc 
drwxr-xr-x 57 root root 4096 2022-01-22 22:49 /etc
root@dm900:~# ls -ald --time-style=long-iso /etc
drwxr-xr-x 57 root root 4096 2022-01-22 23:10 /etc
root@dm900:~# 

Aber meine Box ist sicher nicht die Referenz. Dazu habe ich schon viel zu viel im Linux Unterbau herumgeschraubt und hole mir die aktuelle Zeit sehr früh von einem Zeitserver und mein Image ist am Software stand vom 30.5.2019 ...

das proc filesysstem wird beim booten dynamisch erzeugt und ist scheinbar nach reboot oder stromlosen Zustand weg - aber nicht, wenn die Box vom frontprozessor gestartet wird

ich habe mir in der Zwischenzeit ein systemd service gebaut, dass beim bootup vor dem Netzwerkstart die Paketanzahl des inferface lo aus /proc/net/dev ausliest. Das hat bisher zumindest jeden boot aus dem standby erkannt. Wenn lo packages < 5 wurde sie entweder neu gestartet oder war stromlos, wenn größer kommt sie aus dem standby

die ctime von /proc/stb/fp müsste auch reichen, wenn sie nicht zu früh nach dem start aktualisiert wird

Ich bin vielleicht einen Schritt weiter:

es wird ja nicht nur die ctime der Dateien im proc filesystem behalten sondern auch deren Inhalte wenn die Box aus dem deepstandby hochfährt

z.B. /proc/net/dev

hier werden rx, tx und pakete der Netzwerkschnittstellen geschrieben

nach einem reboot oder stromlosen Zustand wird der Zähler auf 0 gesetzt

über einen command in der rc.local beim bootup ausgelesen, da sieht man schön, dass eth0 0 bytes bzw. pakete empfangen oder gesendet hat

Inter-|   Receive                                                |  Transmit
 face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
    lo:     140       2    0    0    0     0          0         0      140       2    0    0    0     0       0          0
  eth0:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0

die Werte gehen dann natürlich sofort hoch, wenn das Netzwerk aktiv wird

aus dem deepstandby sieht es dann z.B. so aus

Inter-|   Receive                                                |  Transmit
 face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
    lo:    4409      53    0    0    0     0          0         0     4409      53    0    0    0     0       0          0
  eth0: 14578254   10818    0   12    0     0          0         0   196263    2446    0    0    0     0       0          0

die rx/tx Werte eignen sich vermutlich nicht zum Rechnen, weil die Zähler irgendwann wieder bei 0 beginnen soweit ich weiß

jetzt müsste man nur noch ein file im proc file system finden, indem etwas hochgezählt wird mit dem man Arbeiten kann und bei ein reboot auf 0 gesetzt wird und aus dem deepstandby den Inhalt behält

dann könnte man im python die Datei auslesen und aus dem Wert ersehen ob es ein reboot oder boot aus dem deep standby war - dann kann das auslesen vor dem enigma2 Start im OS komplett wegfallen

etwa nach dem Prinzip:

wenn die paketanzahl der schnittstelle lo größer als 100 ist kommt die Box aus dem Deepstandby, wenn der Wert kleiner als 100 ist, war es ein Reboot wenn die Datei standby.chk nicht existiert oder die Box war stromlos wenn die Datei standby.chk existiert

das funktioniert auch bzw. kann man mit der rc.local viel machen - ich habe da einiges eingebaut, dass im Linux Unterbau greift

wenn die Zeit über die Transponderzeit geholt wird hast du vermutlich genügend Zeit. Wenn die Zeit über einen Zeitserver gesynct wird, kann ich nicht sagen ob sich das ausgeht

ich hole mir die aktuelle Zeit beim bootup mit rdate über die rc.local, die ctime habe ich in der rc.local vorher ausgelesen. d.h. wenn die rc.local ausgeführt wird hat die Box vermutlich in keinem Fall die aktuelle Zeit.

Über die Settings kannst zumindest rausfinden ob die Transponderzeit aktiviert ist oder nicht

root@dm7080:/# grep -i TransponderTime /etc/enigma2/settings
config.misc.useTransponderTime=false
root@dm7080:/# 

Bin mir aber jetzt nicht 100% sicher ob das auch im Originalimage greift, nutze ein alternatives OE2.5 Image

alternativ könntest du ein eigenes systemd service basteln, nicht jeder hat das rc-local.service aktiviert

IHMO ist das service by default deaktiviert und die rc.local muss auch manuell erstellt werden

mir fällt gerade ein, die Zeit MUSS irgendwo gespeichert werden bzw. weiterlaufen. Woher weiss die Box sonst ohne Hardware Clock wann sie wg. eines Timer Events im Standby aufwachen muss?

Das erklärt vielleicht auch, warum bei reboot die ctime nicht behalten wird: weil nicht notwendig

Ich such mal im sys ...

Hehe,

jetzt ist es mir wieder eingefallen, wie man das prüfen kann

es wird ja im Betrieb ständig in das proc file system geschrieben, d.h. auch die Dateiattribute wie ctime werden ständig aktualisiert. Vielleicht kann man das zunutze machen, dass die OE2.5 Boxen keine hardware clock haben.

Wenn man die Box in den deepstandby schickt (auch mit shutdown -h now) bleibt die ctime im proc file system erhalten. D.h. die letzte Änderungszeit bleibt erhalten und wird erst überschrieben, wenn sich die Box die aktuelle Zeit wieder vom Zeitserver oder Transponder geholt hat und wieder ins proc file system geschrieben wurde.

Bei einem reboot oder GUI Neustart oder stromlosen zustand wird die ctime des Odners auf Unixzeit zurückgesetzt

Warum auch beim reboot kann ich nicht sagen.

Ich hab mir dann den folgenden command in meine rc.local eingebaut, um die ctime von /proc/stb/fp beim bootup in ein temp file zu schreiben

ls -ald --time-style long-iso /proc/stb/fp > /tmp/proc_stb_fp

nach dem Aufwecken aus dem (deep)standby sieht das so aus - die letzte change time bleibt also erhalten

nach Standby über die GUI oder das Web-IF, oder nach

shtudown -h now

systemctl poweroff

root@dm900:~# cat /tmp/proc_stb_fp 
dr-xr-xr-x 2 root root 0 2022-01-22 15:05 /proc/stb/fp
root@dm900:~# 

Nach einem bewussten stromlos machen oder einem Stromausfall und bei einem reboot/Neustart wird die ctime zurückgesetzt und es wird die Uhr auf die Unixzeit gesetzt: 01.01.1970 00:00 UTC

d.h. nach dem Start aus einem stromlosen Zustand oder reboot sieht das so aus

root@dm900:~# cat /tmp/proc_stb_fp 
dr-xr-xr-x 2 root root 0 1970-01-01 01:00 /proc/stb/fp
root@dm900:~# 

d.h. das Datum 01.01.1970 ist ein Indikator für einen stromlosen Vorzustand - warum auch immer dieser eingetreten ist.

Wenn das ctime Jahr von /proc/stb/fp 1970 ist UND das reboot.chk file vorhanden ist, war es ein geplanter Neustart

Wenn das ctime Jahr von /proc/stb/fp 1970 ist UND das standby.chk file vorhanden ist, hatte die Box im standy einen Stromausfall

Wenn das ctime Jahr von /proc/stb/fp nicht 1970 ist UND das standby.chk file vorhanden ist, hatte die Box im standy keinen Stromausfall
usw.

Ob das für das Plugin nutzbar ist kann ich nicht sagen. Hängt wohl davon ab wie schnell sich die Box über eine Zeitserver oder der Transponderzeit die aktuelle Zeit holt und die ctime des Beispielordners im proc filesystem aktualisiert wird.

Ich habe da noch einen Denkfehler. Ich habe den Beitrag wieder gelöscht weil ich zu vorschnell in die Tasten haute

Irgend etwas klingelt da bei mir, aber vielleicht irre ich mich auch

srry, hier stand Blödsinn ...

das muss ich nochmal genauer durchdenken, da passte die Logik noch nicht

IHMO gehört der ganze Freigaben bzw. Mountmanager längst angepasst bzw. mehr als optimiert, weil da einiges nicht so gut gelöst ist und oft mehr Sorgen als Einfachheit bereitet. Ich mounte die Freigaben nur über die fstab mit systemd im DreamOS.

Nach meiner Erfahrung sollte man die Standardaufnahmepfade anpassen, wenn man mit HDD Ersatz mountet

/media/hdd statt /media/hdd/movie und alles ist gut - dann braucht es auch keinen movie Ordner am NAS etc.

Sauberer ist es NICHT mit HDD Ersatz zu mounten und die Standard Aufnahmepfade auf den Einhängepunkt der Netzwerkfreigabe bzw. auf einen Ordner darin umzustellen

Wenn man mit HDD Ersatz mountet bzw. auf eine Nezwerkfreigabe aufnimmt wäre es am Besten, die Freigabe in eine ram disk (tmpfs) zu mounten damit der Flash nicht platzt, wenn die Aufnahme warum auch immer im file system landet und nicht am share. Nach einem reboot ist dann wieder alles sauber,

ah, das mit dem cache daemon hatten wir schon mal, da gabs mal einen memory leak ...

Ein Neustarten des dreambox teletext cache deamons behebt das aktuelle Problem im OE2.5 aber nicht, am Puffern liegt es glaube ich also nicht

dbttcd ist meines Wissen closed source - da kann nur DP was ändern, wenn es daran liegt