Edit

du machst ja auch im IHAD in der gleichen Tonart weiter ...

für das realease image gibt es keine updates mehr, einmal auf das expirmental Image wechseln und alles aktualisieren wird dir vermutlich nicht erspart bleiben.

Und ohne Bekanntgabe der Tuner Einstellungen und dem SAT Equipment wird dir niemand bei diesem Problem helfen können - ich tippe da eher auf eine falsche Tuner Konfiguration.

around 1GB of available memory is reserved by system/kernel

root@dm900:~# cat /proc/cmdline
bmem=640M@384M bmem=384M@2048M console=ttyS0,1000000 root=/dev/mmcblk1p2 rootwait rootfstype=ext4 coherent_pool=2M
root@dm900:~# dmesg | grep "Memory"
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] Memory: 1006896K/2097152K available (6114K kernel code, 214K rwdata, 1600K rodata, 244K init, 208K bss, 1073872K reserved, 16384K cma-reserved, 786428K highmem)
root@dm900:~#

die Dreamboxen verfügen über keine CI+ Lizenz, dann kommt eben Punkt 2.6.1 der Nutzungsbedingungen zum Tragen - unabhängig davon ob man ein gültiges Abo hat oder nicht

sind auch die USB to UART Treiber am PC intalliert? Das sieht im Bild des Geräte Managers nicht danach aus

die Treiber findet man <hier> und im Gerätemanager sieht das dann etwa so aus, wenn die Box über den Service Port mit dem PC verbunden ist (COM3)

Der COM Port kann aber variieren, muss also nicht COM3 sein. Den richtigen Anschluss erkennt man am Namen

der Weg über USB im 2. Post im verlinkten Thread ist etwas einfacher bzw. weniger aufwendig als der Weg über TFTP im Eingangspost

Quote from flipper1980

Danke trotzdem euch allen für die Hilfe, ich wollte keinen Streit oder Stress vom Zaun brechen ..

Du hast keinen Stress oder Streit vom Zaun gebrochen. Das Problem ist ja schon länger bekannt und wird von den open* Dev's nicht wahr genommen oder ignoriert.

Aktuell sind jetzt zwei one Besitzer innerhalb kurzer Zeit mit dem selben Problem hier aufgeschlagen und haben dieses Thema mal wieder hochgeschaukelt.

Quote from flipper1980

.. Ich habe dann meine One daher der "schnelle" Umstieg ohne mich tatsächlich richtig zu informieren auf das OpenATV ...

Und genau das ist die Falle in die User, die nicht am Laufenden sind, tappen können. Das habe ich auch bei den Piraten angesprochen und das darf imho nicht passieren oder zumindest repariert werden anstatt es zu ignorieren.

Frag doch mal im openATV Board nach was die dazu meinen.

in diesem Thread ist so ziemlich alles behandelt und beschrieben worden was man alles versuchen kann -> Dreambox One rote led blinkt

Einfach mal am Stück reinziehen und/oder gleichzeitig testen

spuckt die konsole etwas mit baud rate 300 aus?

Vielleicht war amlogic anfangs nicht dafür bereit? Die Frage kann vermutlich nur dp beantworten.

Und was meinst du mit der Inkompatibilität dm9x0 und dreamone/two? das Flashlayout/BIOS der dm5x0 und dm820hd/dm7080hd ist auch anders und hat genau null mit diesem Thema hier zu tun - genauso wenig wie die Prozessor Architektur

Danke! Aber lass es - aber die message kommt bei ihm nicht an, aus welchem Grund auch immer.

Was mich an der Geschichte ärgert, ist dass sich dann meist gerade mal 3 Leute mit dem Thema befassen (dürfen/müssen) wenn das Flashen/Update des open image schief geht und sich die Verantwortlichen wie üblich abputzen und allen anderen inklusive Naturgewalten die Schuld dafür geben anstatt die Ursache zu beheben - was ja nicht unmöglich ist

In this thread a dm900 is not affected and a thunderstorm lightning will not overwrite the u-boot - especially not in winter

And yes - please shut down all your STB's, disconnect the power and LAN cables and stop your stupid posts because your translation tools seems even more stupid than you are. And everyone will be happy ...

Genau! Ein Gewitter im Winter bei Minusgraden hat die Box gekillt ...

Wie immer ist das buggy open* image - nicht - schuld!

Glaubst du diesen bullshit eigentlich selbst?

GPT heisst, dass enhanced rescue-rescue image (#124) installiert, den flash auf GPT umgestellt - entweder mit einer Image Partition oder mehre für Multiboot

Im openATV Board findet man ja immer noch den Thread wie man die alte Version #112G per wget script installiert und nicht über den gm3 feed ...

Lustig finde ich, dass die Leute mit einem openATV im Flash der one/two dann immer hier anstatt im openATV Board aufschlagen, wenn die Box nach einem update oder beim Flashen des Images zum Briefbeschwerer geworden ist - siehe auch z.'B. hier: Dreambox One rote led blinkt

da kannst du dich mal einlesen, da wurde bereits alles behandelt was du jetzt noch noch versuchen kannst

Ihr könntet ja auch mal den Dev's vom openATV Image in den A* treten damit sie das reparieren. Aber wie ich die kenne, werden die eher den support für die one/two einstellen: not supported - ist ja alles closed socure. Und hol dir Hilfe im Dreambox Lager ...

Und sie werden sich dann auch nicht weiter die Finger schmutzig machen, wenn noch weitere Boxen zum Briefbeschwerer verwandelt worden sind. Zudem wird dir vermutlich sicher erstes geraten, die aktuelle Version ATV 7.6 zu installieren - als ob das noch funktionieren oder etwas ändern würde

...

Aber wenigstens gäbe es dann keine updates mehr - also ein Risiko weniger ...

Nur wenn man die lamedb mitkopiert.

Und ich bin mir nicht sicher ob ich den ersten Post richtig verstanden habe. Kopierst du wirkliche den gesamten Inhalt von /etc/enigma2 von Box A auf Box B oder nur diese:

lamedb

bouquets.radio

bouquets.tv

userbouquet.*.tv

userbouquet.*.radio

Ich kann mir nicht vorstellen, dass das gut ausgeht, wenn man /etc/enigma2/* zwischen den Images hin und her kopiert - schon gar nicht zwischen DreamOS und open*. Deshalb glaube ich, dass du nur bestimmte Dateien aus /etc/enigma2 kopierst - und dann wäre es mal gut zu wissen welche

Quote from gutemine

Insofern ist es im Flash meines Erachtens auch sinnvoller den einfach vergammeln zu lassen bis sowieso wieder mal geflashed wird und selbst auf dem Aufnahmedevice nicht zu übertreiben und z.B.. nur Monatlich zu trimmen, aber das kann ja jeder selber entscheiden.

wenigstens sind wir da einmal einer Meinung

Ich bin auch vor längerer Zeit beim "monthly" Intervall gelandet, wobei ich bei einer "fast vollen" und unaufgeräumten SSD gerne manuell trimme, nachdem ich größere Datenmengen aus Platzmangel auf einmal lösche

Die eigentliche Frage bezüglich der Sinnhaftigkeit den Flash zu trimmen hast du aber schon gelesen? Da würde es deiner Aussage ja sogar mehr Sinn machen ...

Und das soll jetzt nicht (schon wieder) in eine gm3 Werbeveranstaltung ausarten und das wäre auch anders lösbar ...

Ich hätte mal eine Frage zu fstrim:

Im DreamOS gibt es ja keinen fstrim systemd timer der z.B- wöchentlich alle gemounteten supporteten filesysteme wie in modernen Linux distributionen trimmt. Das würde ja auch halbherzig funktionieren weil die Dreamboxen keine realtime clock haben und das journal bei einem reboot gelöscht und bei längerer Laufzeit "gekürzt" wird.

Ich bin gerade dabei mir ein systemd timer gesteuertes fstrim.service zu schreiben, das einen timestamp im nichtflüchtigen Speicher ablegt um vergangene Zeitperioden zwischen den fstrim Läufen zu prüfen. Das hat den Vorteil, dass im Gegensatz zum "versäumten" cronjob systemd beim nächsten Start den job ausführt. Das könnte man auch mit cron lösen, aber ich finde eine systemd Lösung eleganter

Das buxycron fstrim kann nur definierte moint points trimmen, und das fstrim binary im util-linux-fstrim Paket kennt zwar die Option '-a' aber nicht die Option '-I' wie aktuelle fstrim Versionen, um bestimmte mointpoints in einer Datei zu definieren

Options:
 -a, --all                trim mounted filesystems
 -I, --listed-in <list>   trim filesystems listed in specified files

Jetzt zu meiner Frage:

Um die Konfiguration so einfach wie möglich zu gestalten, ist die Verlockung groß fstrim -a ausführen zu lassen. Dann werden alle gemounteten Dateisysteme getrimmt, sofern TRIM supportet wird - und man muss keine Einhängepunkte definieren, was das ganze wesentlich vereinfachen würde, wenn man diesen systemd-fstrim-timer puplic zur Verfügung stellen möchte.

Allerdings wird damit auch der Flash getrimmt. Macht das Sinn oder schadet das dem Flash Speicher? Wird der Flash überhaupt getrimmt oder ist das pseudo wie bei machen SD Karten, was ich bei der internet Rechere herausgefunden habe.

root@dm900:~# fstrim -v /
/: 233,7 MiB (245006336 bytes) trimmed
root@dm900:~# fstrim -v /data
/data: 0 B (0 bytes) trimmed
root@dm900:~# 

root@dreambox:~# fstrim -av
/data: 0 B (0 bytes) trimmed
/media/hdd: 0 B (0 bytes) trimmed
/: 0 B (0 bytes) trimmed
root@dreambox:~# 

Edit:
Ganz vergessen. Das betrifft aber nur die dm9x0 und die one/two. Drr Flash der mipsel Boxen unterstützt kein trim, da kann man fstrim -a bedenkenlos verwenden

root@dm820:~# fstrim -av
root@dm820:~# fstrim -v /data
fstrim: /data: the discard operation is not supported
root@dm820:~# 

die Anleitung ist uralt und stammt glaube ich noch aus OE1.6 Zeiten und galt für die Shell sh anstatt aktuell bash im OE2.5

Grundsätzlich kann man das so machen, allerdings ist das nicht Update sicher - wobei es vermutlich keine Updates mehr gibt ...

alternativ erstellt man eine eigene .sh Datei in /etc/profile.d/ - die überlebt dann auch ein etwaiges update der /etc/profile

z.B. /etc/profile.d/my_default_editor.sh mit folgendem Inhalt:

export EDITOR="nano"

danach liest man die Datei manuell ein (erspart den reboot)

root@dm900:~# echo $EDITOR
vi
root@dm900:~# echo 'export EDITOR="nano"' > /etc/profile.d/my_default_editor.sh
root@dm900:~# source /etc/profile.d/my_default_editor.sh
root@dm900:~# echo $EDITOR
nano
root@dm900:~# 

Beim systemstart wird die /etc/profile.d/my_default_editor.sh nach der /etc/profile geladen und "überschreibt" dann die Umgebungsvariable EDITOR

ich würde mich aber trotzdem mal mit vi oder vim (über den feed installierbar) auseinandersetzen, zumindest die grundsätzlichen bzw. am häufigsten verwendente Befehle.

vi ist auf nahezu jedem System default vorinstalliert - was bei nano nicht zutrifft. Wenn keine Internetverbindung besteht, kann man nano auch nicht nachinstallieren und muss sich dann mit vi offline auseinandersetzten

zudem ist vi(m) viel mächtiger und umfangreicher als nano

crontab -l listet den Inhalt der Crontab Datei, d.h. die von dir eingefügte Zeile müsste dann ausgeben werden

Man könnte auch ein "logging" einbauen, z.B. in den crontab selbst, aber der wird dann schnell unübersichtlich und umständlich. Oder man kann das dann in ein kleines shell Script packen und statt dem fstrim Befehl das script aufrufen

crontab mit Ausgabe in ein logfile in zum /tmp:

0 2 * * 0 /sbin/fstrim -v /media/SDUltra3D2TB >> /tmp/fstrim.log

Das Datum, wann der crontab ausgefürt wurde, sieht man so aber nicht - ausser am Zeitstempel (Änderungsdatum) der Datei. Aber das könnte man dann so lösen, damit das Datum auch im log file steht:

0 2 * * 0 /bin/echo $(/bin/date) >> /tmp/fstrim.log; /sbin/fstrim -v /media/SDUltra3D2TB >> /tmp/fstrim.log

Um zu testen ob das funktioniert, kann man den crontab ja mal stündlich laufen lassen, dann sieht man ob das logfile angelegt und befüllt wird.

Nach jeder Änderung des crontab muss man das cron.service neu starten, damit die Änderung übernommen wird.

systemctl restart busybox-cron.service

/tmp/fstrim.log ist nach einem reboot wieder leer, wenn man dauerhaft "loggen" will, muss man das in einen nicht flüchtigen Speicher schreiben.

Im DreamOS verwendet man apt oder apt-get für die Paketverwaltung, opkg ist veraltet und wurde eigentlich nur für die "Umgewöhnungsphase" eingebaut. Solltest du ein open* Image verwenden, das nur opkg kann, fragst du im falschen Board nach Support. Wenn dir die KI das "erzählt" hat, ist das wieder ein Beweis dafür, dass man ihr nicht trauen kann. Die vermischt die unterschiedlichen OE's bzw. nimmt Dinge für allgemein gültig an - was dann auch gerne mal dazu führt, dass die Dinge nicht so funktionieren wie man sich das wünscht ...