debug.dat

[Fusion]

Ich hab letzt auch besseren Wissens eingeschickt, weil ich einfach zu genervt war. Ein leicht ungutes Gefühl bleibt, weil man nicht weiß, wann, ob, wie die Daten entsorgt werden.
Man kann aber auch konkret nachfragen welche Daten sie brauchen und diese separat schicken.
Die debug.dat komplett zu anonymisieren wird wohl am Zeitaufwand scheitern.
Manchmal lassen sie sich auch auf eine Teamviewer Sitzung ein, dann kann man wenigstens über die Schulter schauen, was sie so treiben.

Eine Lösung die sowohl dem Persönlichkeits- wie auch Datenschutz komplett gerecht wird fällt mir gerade keine ein (außer dem was wir hier treiben: Selbsthilfe-Gruppe )

 

[Tommes]

Naja, solang sich keine schützenswerte Inhalte auf der DS befinden kann man die debug.dat ja ruhigen Gewissens verschicken. Hab ich damals mit einem frisch aufgesetztem DSM auf einer genullten HDD so praktiziert um dem Boot-Problem der DS216+ auf den Grund zu gehen. Nur ist dieses Vorgehen ja eher die Ausnahme und eigentlich nicht praxistauglich.

Tommes

 

[peter_muc]

Tja wenn ich das wüsste, bei 150 MB kann man sich nie sicher sein.

Naja, solang sich keine schützenswerte Inhalte auf der DS befinden kann man die debug.dat ja ruhigen Gewissens verschicken..

Tommes

 

[PsychoHH]

Nur ist dieses Vorgehen ja eher die Ausnahme und eigentlich nicht praxistauglich.

Seh ich auch so: ziemlich viel Aufwand, besonders wenn der Fehler dann nicht immer auftritt.

 

[tuep]

Kann mir jemand sagen, wo ich in der debug.dat die Ergebnisse vom Speichertest des Synology Assitant finde?
Ich würde vermuten, dass dieser Speichertest sowas wie fsck.ext4 macht.

Aber ich kann irgendwie keine passende Datei finden.

 

[DKeppi]

Du suchst die debug.dat?

SupportCenter im DSM öffnen - SupportDienste - ganz unten auf Protokoll erstellen (nachdem du das was du brauchst angehakt hast!)

 

[tuep]

Nein, die debug.dat habe ich schon und ich habe sie auch entpackt.
Ich habe auch im Ordner results zum beispiel die Ergebnisse vom Smart Test gefunden. Ich habe aber auch über den Synology Assistant einen Speichertest durchgeführt. Das Bescheuerte ist nur, dass der Assistant nach beendigung kein Ergebnis abliefert. Dieses wird anscheinend nur irgendwo in der debug.dat gespeichert. Ich konnte allerdings nicht herausfinden wo das Protokoll davon sein soll. Meine Hoffnung ist jetzt, dass es von euch jemand weiß.

Wenn ansonsten das Protokoll auf dem ausführenden Computer zu finden ist, wäre das auch eine Lösung.

 

[Fusion]

Der Speichertest testet den RAM / Arbeitsspeicher der DS, nicht die Festplatten.
Wenn der Test keine Meldung liefert wurden keine Fehler gefunden.
Der Test wird, da erst ein Neustart erfolgt, vermutlich via Memtestx86 gefahren. Das läuft außerhalb/vor dem Linux OS, deshalb hat dieser auch keine Chance etwas in eine Log-Datei dort zu schreiben, weil auch die RAIDs etc alle nicht aktiv sind.

Die Ergebnisse von SMART Tests von Festplatten spiegeln sich direkt in den SMART Werten wieder die man im Speichermanager bei HDD/SSD finden kann. Wenn ein Fehler hinzugekommen ist, steigen dort die Werte.

 

[tuep]

Dann gibt es gar keine offizielle Möglichkeit einen fs check zu machen?

 

[Fusion]

Wußte ja nicht genau auf was du hinaus willst.

Bei btrfs bin ich mir gerade nicht sicher, ob die Dateisystem-Defragmentierung auch eine Prüfung enthält.
Bei ext4 gibt es gar keine Option im Speichermanager.

Im DSM kenne ich keine Möglichkeit, wenn du das als "offiziell" ansehen willst.

Auf der Konsole geht es hingegen schon. Man muss eben dafür sorgen, dass alle Dienste heruntergefahren und das Volumen ausgehängt ist. *Achtung, folgendes aus dem Gedächtnis zitiert*
Befehlsreihenfolge
syno_poweroff_task -d
umount /volume1 (replace this with your volume name)
fsck.ext4 -pvf /dev/md0 (replace this with your dev)
reboot

 

[goetz]

Hallo,

usage: syno_poweroff_task [OPTIONS]
  -h            display this help
  -d            debug mode

also mit der Option -d sonst ist die Kiste aus.

Gruß Götz

 

[tuep]

Ich hab das gestern versucht.

Erstes seltsames Problem. ssh root@ip ging nicht. Das Passwort wurde nicht akzeptiert.
admin@ip ging aber. Da musste ich allerdings immer sudo mitbenutzen.
Ich weiss nicht mehr, welchen Parameter für Poweroff hatte, ich meine ich hätte hier irgendwo s gelesen. Jedenfalls blieb volume1 busy.
Dann hab ich es ohne Parameter versucht und die DS wurde nicht mehr ansprechbar. Konnte auch nicht ausschalten und musste dann den Stecker ziehen.

 

[Fusion]

Dass root nur noch per Zertifikats Login funktioniert oder eben via admin login und sudo -i gemacht werden muss ist inzwischen ein "alter" Hut.

Den Parameter -d für den debug mode haben wir ja auch schon genannt inzwischen.