D.h. dann müsste die "langsamere" SD in der Two höhere Schreibraten erreichen. Das könnte auch am verbauten Card Reader liegen.

Ein einfacher Schreibtest würde da helfen um herauszufinden wie sich die Boxen unterscheiden.

Schreibt ein 1GB Testfile gefüllt mit Nullen ("/mountpointSD" durch den korrekten mountpoint ersetzen, z.B. /media/sd etc.)

dd if=/dev/zero of=/mountpointSD/writetest bs=1M count=1000

wenn man noch status=progress anhängt, kann man die performance "mitlesen"

dd if=/dev/zero of=/mountpointSD/writetest bs=1M count=1000 status=progress

Was hat das mit Support von BA zu tun?

Ein USB-Stick oder SD Card kann aus allen möglichen Gründen plötzlich schreibgeschützt sein. Das passierte mir auch schon zwei mal - ohne BA.

Wenn der TE nur schreibt, dass die SD write prodtcted ist - ohne Angabe wann/wie das passiert, kümmert sich niemand darum ob das BA Support ist oder nicht.

Und wenn er die SD einfach nur gerne weiterverwenden möcht, ohne BA darauf zu installieren. Ist das deine Meinung nach dann auch BA Support?
In diesem Threat ging es NUR darum, den Schreibschutz einer SD zu entfernen - um nichts anderes!

Ich gehöre vermutlich zu den letzten, der BA hier oder sonst wo supporten würde. Und ich glaube, dass ist kein Geheimnis ...

Wenn du nichts fachliches Beitragen kannst, troll doch bitte wo anders rum.

It is of course also possible that the SD card has died ..

Check first if your SD card is physically locked by tape or slider. You can use the command prompt and diskpart on Windows or on linux (dreambox) hdparm to unlock your SD card. Since there is no information about your used Dreambox may be no full hparm binary is installed or available and the busybox hdparm does not support unlock write protection.

In DreamOS hdparm can be installed online:

apt-get update && apt-get install hdparm

To find out the correct device name of your SD Card use blkid or lsblk, for example on a DM900UHD:

root@dm900:~# lsblk
NAME         MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda            8:0    0  1,8T  0 disk 
├─sda1         8:1    0  1,8T  0 part /media/hdd
└─sda2         8:2    0 1023M  0 part 
mmcblk0rpmb  179:32   0  512K  0 disk 
mmcblk0boot0 179:16   0    4M  1 disk 
mmcblk0boot1 179:24   0    4M  1 disk 
mmcblk0      179:8    0  3,7G  0 disk 
├─mmcblk0p1  179:9    0   31M  0 part 
├─mmcblk0p2  179:10   0  992M  0 part /
└─mmcblk0p3  179:11   0  2,7G  0 part /data
mmcblk1      179:0    0 14,9G  0 disk 
└─mmcblk1p1  179:1    0 14,9G  0 part /media/sd
mtdblock0     31:0    0    2M  0 disk 
mtdblock1     31:1    0  128K  0 disk 
mtdblock2     31:2    0  128K  0 disk 
mtdblock3     31:3    0 13,8M  0 disk 
mtdblock4     31:4    0   32M  0 disk 
root@dm900:~# 

be aware! /dev/mmcblk0 is the internal emmc flash - do not touch!

/dev/mmcblk1 should be the SD Card and should be unmounted. To unlock the write prodection try

hdparm -r0 /dev/mmcblk1

And sometimes google is your friend. I found at least 5 different ways to unlock a SD Card on different devices within one minute

How To Remove Write Protection From an SD Card

3 Ways to Remove Write Protecion on a SD Card

sieht mir nach defektem Flash aus

[  171.073967] mmcblk0: error -110 sending status command, retrying
[  171.077382] mmcblk0: error -110 sending status command, aborting
[  171.078438] end_request: I/O error, dev mmcblk0, sector 0
[  171.079354] Buffer I/O error on device mmcblk0, logical block 0
[  171.080674] ldm_validate_partition_table(): Disk read failed.

Ist doch einfach nachzurechnen

ausschlaggebend sind die Lade/Entladezyklen der Platte - die limitieren die Lebensdauer einer Festplatte, nicht die Betriebsstunden

die WD RED soll z.B. nicht in den Standby Modus geschickt werden, die ist auf den Dauerbetrieb ausgelegt - sonst muss man bei jedem Zugriff warten bis die Platte anspringt. d.h. wenn kein Standby gesetzt ist und das NAS 1x täglich für x Stunden ausgeschaltet wird, ist das ein Lade/Entladezyklus/Tag. Das ist zu vernachlässigen. Btw. lassen sich die WD Red gar nicht in standby setzen ...

Wenn die Platte nach 10min Inaktivität in Standby geht, sind das bis zu 144 Lade/Entladezyklen/Tag

Ergo ist es egal ob die Platte 12 oder 24h läuft, wenn kein Standby gesetzt ist. Wenn die Platte nach 2 Minuten in Standby geht wird die Lebensdauer ihmo verdoppelt, wenn sie nur 12h am Tag läuft. Dafür sinken die Stromkosten

Ob das ein Nullsummenspiel inkl. Datenrecovery nach einem Ausfall ist, kann jeden selbst ausrechnen ...

das ist "nur" die Hardware schonende Alternative zum Irrwitzigen Vorschlag mit dem Föhn die Box zu überhitzen

Aber ja, so kann man Testen ob das Gerät unter Volllast sauber läuft und nicht abschmiert

Enigma2/die Box wird bei bei diesem Test dann aber merklich träger

unter Normalbedingungen wird man die One/Two nie voll auslasten bzw. die CPU dauerhaft auf 100% Last bringen können

ich mache immer mit dd einen CPU Stresstest

einfach mit dd Nullen nach /dev/null ins nirvana jagen - das jagt die CPU Last auf 100% hoch, je nach CPU den Prozess 4-20 mal starten

z.B. den Prozess 20x im Hintergrund laufen lassen:

for pid in $(seq 1 20);do $(dd if=/dev/zero of=/dev/null &);done

dann fährt die CPU am Limit und die CPU Temperatur geht hoch

die Prozesse laufen solange bis man die Box neu startet oder manuell killt

killall dd

die dm9x0 CPU habe ich so auf über 90°C bekommen

Ich habe auf diese Art den Stromverbrauch meines NAS mit einer Intel CPU optimiert

mit tlp die CPU Freqeunz auf x % limitiert und dann mit dd Vollast provoziert den Stromverbrauch und den CPU Temperatur gemessen

imho gibt es dafür kein plugin, das müsste man selber frickeln

das plugin müsste periodisch die timerlist prüfen und dann z.B. 5 Minuten vor der Timeraufnahme prüfen ob A das NAS bzw. der Aufnahmepfad online ist und dann B, falls erforderlich, das NAS mit einem magic packet wecken. Würde nur funktionieren, wenn die Box auch läuft - aus dem (Deep)standby wird das schwierig(er)

Nach der Aufnahme müsste die Box dann auch das NAS wieder in standby schicken - sofern das NAS das zulässt. Ginge z.b. über einen SSH command

sorry, aber die GUI habe ich seit Jahren nicht mehr für die Paketverwaltung verwendet. Unübersichtlicher und komplizierter geht es ja nimmer

apt-get update

apt-cache search emc

OK

Nach der Theorie von alpha hätte es mit systemctl --no-block reboot auch nicht klacken dürfen/sollen.

Klackt die Platte eigentlich auch, wenn man die Box mit der FB neu startet? Hier müsste nach meiner Theorie der selbe Code ausgeführt werden wie über das WebInterface ausgeführt.

ich würde es so versuchen

sync && shutdown -r now

sync && reboot

sync && systemctl reboot

ich glaube aber nicht das sich daran etwas ändert

hast du eigentlich auch schon den Tipp von alpha getestet??

systemctl --no-block reboot

dazu fand ich noch keine Rückmeldung

interesant

dennoch würde mich jetzt brennend interessieren ob dreamboxctl reboot die Platte nicht klacken lässt ...

ich vermute das über Enigma2 die Box anders rebootet wird als über reboot, shutdown -r now etc. im Terminal

der Befehl dreamboxctl reboot müsste die Box wie über das Webinterface rebooten - also ohne Klacken der Platte

dreamboxctl ist ein python script von DP, dass die selben Routinen für den reboot verwendet, wie das WebInterface. Das Script funktioniert aber nur dann, wenn Enigma2 läuft. Wenn E2 nicht läuft, gibt es bei der Ausführung einen Fehler.

Ich konnte bisher noch nicht herausfinden, wie Enigma2 rebootet - ich vermute das steckt im closed Enigma2 Core verborgen.

Tatsache ist, dass /sbin/shtudown und /sbin/reboot auf systemctl verlinkt sind, aber teilweise nicht sauber durchläuft - dass ist mir auch schon bei den Beta Tests mit Sven H bei seinem StartupToStandby Plugin aufgefallen

root@dm820:~# update-alternatives --display reboot
reboot - auto mode
  link best version is /bin/systemctl
  link currently points to /bin/systemctl
  link reboot is /sbin/reboot
/bin/systemctl - priority 300
root@dm820:~# update-alternatives --display shutdown
shutdown - auto mode
  link best version is /bin/systemctl
  link currently points to /bin/systemctl
  link shutdown is /sbin/shutdown
/bin/systemctl - priority 300
root@dm820:~# 

Tatsache ist, dass dreamboxctl mit systemd im OE2.2 erstmal auftauchte, dass wird vermutlich seine Gründe haben

ich habe das mal nachgespielt und kann dieses Klacken von meiner Platte nicht bestätigen

jetzt wäre ein bootlog von einem "reboot" im Terminal und eine reboot übers WebInterface interessant ob es da einen Unterschied gib

Edit:

Klackt es auch wenn du folgenden command für einen reboot im Terminal verwendest? ich vermute jetzt mal nein

dreamboxctl reboot

das spuckt allerdings nur alle in der busyox befindlichen commands, aber nicht die installierten binaries oder aliases

bis OE2.0 konnte man mit 2x TAB alle Befehle listen und/oder mit grep filtern, ab OE2.2 müsste es mit comgen funktionieren

compgen -ac

listet alle binaries, scripte und aliases die in den Ordner der Umgebungsvariable $PATH liegen

die Liste wird sehr lang werden, entweder mit less (blättern) oder mit grep (nach string suchen) durch die pipe jagen was aber nur etwas bringt, wenn man weiß wonach man sucht

compgen -ac|less

compgen -ac|grep power

oder in eine .txt Datei schreiben

compgen -ac>/tmp/command_list.txt

Die 4 Befehle bewirken doch alle etwas vollig anders

reboot startet das ganze System neu, inkl. enigma2
shutdown -h now fährt das ganze System inkl. enigma2 sauber runter - h steht für halt

Das init-x System wird im Dream OS nicht verwendet, sondern systemd

der init Befehl ist nur eine "Umlenkung" auf systemd

systemctl stop enigma2 - stoppt Enigma2

systemctl restart enigma2 - stoppt und startet anschließend Enigma2 wieder

Der gesamte DreamOS Linux Unterbau läuft dabei aber ununterbrochen weiter.

wäre eben mal gut zu wissen was du eigentlich genau tun willst

Wenn es nur um den sauberen Shutdown der Box geht, versuche es mal über die Fernbedienung -> Herunterfahren
rödelt die Platte auch "ungesund"?
btw. meine Platten machen das auch nach einem shutdown -h now oder -r now nicht

sonst versuche mal

poweroff

oder

systemctl poweroff

dabei sollten, wenn DP alles richtig gemacht hat, von systemd alle Dienste und Programme inkl. Enigma2 sauber in er richtigen Reihenfolge beendet werden um anschließend das System komplett runterzufahren. Das entspricht dem Standby über die FB - wie auch shutdown -h now. Wobei dieser Befehl vom init-x-system "übernommen" wurde und ebenso ohne Probleme funktionieren sollte. Man wollte ja bei der Einführung von systemd nicht alles neu erfinden bzw. neu benennen ...

Und ich fahre meine DreamOS Boxen seit Jahren mit shutdown -h now runter bzw. sie mit dem Schalter -r neu. Mir wäre dabei noch nie aufgefallen dass die Platte bei diesen Befehlen lauter werden würde als sonst. Es ist also völlig normal, dass die Platte anläuft und Geräuschte macht.

Bei einem shutdown - egal wie angestoßen - wird die Platte aufgeweckt, wenn sie vorher in Standby war, weil das System sie sauber umounted bevor sie alles abschaltet, damit das Dateisystem eben nicht beschädigt wird. Einer Platte darf das nichts ausmachen, ausser sie ist bereits beschädigt und pfeift aus dem letzten Loch ..

Was bei deinem beschriebenen systemctl stop enigma2 NICHT passiert, weil ja das system nicht runtergefahren wird.

naja, neu flashen ist nicht unbedingt angesagt

vermutlich ist noch die alte Platte in den settings und in der fstab hinterlegt, und die kann nicht mehr gemountet werden

die neue Platte ist noch nicht im system hinterlegt

normalerweise sollte die Box dennoch booten

gibt es einen crashlog? der wäre hilfreich

sonst mal im journal suchen was da schief läuft

Jedenfalls denke ich, dass man das reparieren kann ohne neu zu flashen, mehr Infos wären eben gut (crashlog, enigma2 log, journal etc.)

die Befehle waren schon richtig, nur meine Anleitung nicht - sorry ...

ext4 ist nicht abwärtskompatibel zu ext3, das funktioniert leider nicht - das habe ich verwechselt (umgekehrt ginge es)

im OE2.0 war ext3 standard - wg. Abwärtskompatibilität und weil ext4 Probleme machte

aber der kernel müsste ext4 unterstützen

funktioniert das manuelle mounten mit

mount -t ext4 /dev/sda1 /media/hdd

oder

mount /dev/sda1 /media/hdd

ich schreibe aus Erfahrung

glaub mir, mounten über die uuid der Partition ist auf Dauer der sicherere Weg - vor allem dann, wenn der user nicht so sattelfest ist ...