Unraid nicht mehr erreichbar

[Cupra-Bo]

befehl hab ich mal gemacht

 

Hab ja schon alle USB devices abgesteckt Hub usw.. conbee Stick war noch dran ... den hab ich jetzt in den Nuc gesteckt, somit kein USB gerät mehr dran bis auf der Unraid Stick selber

 

Der USB Stick war Nagelneu da mir mein alter abgeraucht ist aber ja könnte sein 🤔

 

Hier mal meine Notiz liste

15.12.2021   -->> Netzteil umgebaut auf Corsair

17.12.2021 ca 15 uhr dead
25.12.2021 18:45 uhr dead --> onboard lan komplett ausgemacht und ausgesteckt
27.12.2021 DEAD
31.12.2021 1 uhr ca dead

2.1.2022 umbau auf neuen CPU und Board

5.1.2022 23:22 mit neuer Hardware Crash -->> Meinen Ram ausgebaut
8.1.2022     Crash USB HDD enfernt 
12.01.2022   Crash  Conbee Stick umzug zum NUC

 

Hat halt auch irgendwie kein Muster

Edited January 12, 2022 by Cupra-Bo

[mgutt]

Führe auch das bitte aus:

echo 100 > /proc/sys/vm/dirty_writeback_centisecs

 

Das deaktiviert quasi den Linux Page Cache, der normalerweise alle Schreibvorgänge 30 Sekunden lang im RAM sammelt (oben genanntes Kommando reduziert das auf 100ms).

[Cupra-Bo]

oki auch Gemacht jetzt heißt es wieder paar Tage warten

[Cupra-Bo]

So heute nacht war es wieder so weit ...

 

Syslog von der SSD

 

Jan 14 13:26:43 Tower emhttpd: read SMART /dev/sde
Jan 14 13:26:43 Tower emhttpd: read SMART /dev/sdb
Jan 14 13:53:36 Tower emhttpd: read SMART /dev/sdd
Jan 14 14:55:45 Tower emhttpd: spinning down /dev/sdd
Jan 14 15:38:31 Tower webGUI: Successful login user root from 192.168.177.109
Jan 14 17:00:19 Tower webGUI: Successful login user root from 192.168.177.109
Jan 14 17:00:38 Tower emhttpd: cmd: /usr/local/emhttp/plugins/community.applications/scripts/pluginInstall.php install https://github.com/ich777/intel-gpu-top/raw/master/intel-gpu-top.plg
Jan 14 17:00:38 Tower root: plugin: running: anonymous
Jan 14 17:00:38 Tower root: plugin: creating: /boot/config/plugins/intel-gpu-top/intel.gpu.top-2021.07.16.txz - downloading from URL https://github.com/ich777/intel-gpu-top/raw/master/packages/intel.gpu.top-2021.07.16.txz
Jan 14 17:00:39 Tower root: plugin: checking: /boot/config/plugins/intel-gpu-top/intel.gpu.top-2021.07.16.txz - MD5
Jan 14 17:00:39 Tower root: plugin: running: /boot/config/plugins/intel-gpu-top/intel.gpu.top-2021.07.16.txz
Jan 14 17:00:39 Tower root: plugin: creating: /usr/local/emhttp/plugins/intel-gpu-top/README.md - from INLINE content
Jan 14 17:00:39 Tower root: plugin: running: anonymous
Jan 14 17:01:37 Tower nginx: 2022/01/14 17:01:37 [error] 5342#5342: *1368254 open() "/usr/local/emhttp/plugins/dynamix.system.stats/images/sys.png" failed (2: No such file or directory) while sending to client, client: 192.168.177.109, server: , request: "GET /plugins/dynamix.system.stats/images/sys.png HTTP/1.1", host: "192.168.177.2", referrer: "http://192.168.177.2/Stats"
Jan 14 17:01:42 Tower emhttpd: read SMART /dev/sdd
Jan 14 18:01:48 Tower emhttpd: spinning down /dev/sdd
Jan 14 19:02:20 Tower rpc.mountd[5244]: authenticated mount request from 192.168.177.4:684 for /mnt/user/Aufnahmen (/mnt/user/Aufnahmen)
Jan 14 19:02:40 Tower rpc.mountd[5244]: authenticated mount request from 192.168.177.4:978 for /mnt/user/Aufnahmen (/mnt/user/Aufnahmen)
Jan 15 01:00:54 Tower rpc.mountd[5244]: authenticated mount request from 192.168.177.4:865 for /mnt/user/Aufnahmen (/mnt/user/Aufnahmen)
Jan 15 03:39:55 Tower emhttpd: spinning down /dev/sde
Jan 15 03:39:55 Tower emhttpd: spinning down /dev/sdb
Jan 15 03:40:01 Tower root: mover: started
Jan 15 03:40:01 Tower root: mover: finished

 

 

Doch der USB Stick? schnelle möglichkeit nen Backup auf nen anderen Stick zu packen ohne ID problemen ?

Hab hier glaub ich noch nen Stick wo ich noch paar Tage Test hab wie zieh ich alles um ?

 

wäre so die letzte idee die ich habe

[mgutt]

10 minutes ago, Cupra-Bo said:

Doch der USB Stick?

Woraus schlussfolgerst du das? Sind diese Logs nicht auf dem Stick gelandet oder wie?

 

11 minutes ago, Cupra-Bo said:

schnelle möglichkeit nen Backup auf nen anderen Stick zu packen ohne ID problemen ?

Einfach neuen Stick mit dem Creator fertig machen, Dateien aus dem Backup drüber bügeln und starten. Ein Assistent geht dann auf und überträgt die Lizenz auf die neue ID.

[Cupra-Bo]

25 minutes ago, mgutt said:

Woraus schlussfolgerst du das? Sind diese Logs nicht auf dem Stick gelandet oder wie?

 

Nein aber ich sehe fast keine andere Möglichkeit mehr

 

Hier der Log vom Stick

 

Jan 14 15:38:31 Tower webGUI: Successful login user root from 192.168.177.109
Jan 14 17:00:19 Tower webGUI: Successful login user root from 192.168.177.109
Jan 14 17:00:38 Tower emhttpd: cmd: /usr/local/emhttp/plugins/community.applications/scripts/pluginInstall.php install https://github.com/ich777/intel-gpu-top/raw/master/intel-gpu-top.plg
Jan 14 17:00:38 Tower root: plugin: running: anonymous
Jan 14 17:00:38 Tower root: plugin: creating: /boot/config/plugins/intel-gpu-top/intel.gpu.top-2021.07.16.txz - downloading from URL https://github.com/ich777/intel-gpu-top/raw/master/packages/intel.gpu.top-2021.07.16.txz
Jan 14 17:00:39 Tower root: plugin: checking: /boot/config/plugins/intel-gpu-top/intel.gpu.top-2021.07.16.txz - MD5
Jan 14 17:00:39 Tower root: plugin: running: /boot/config/plugins/intel-gpu-top/intel.gpu.top-2021.07.16.txz
Jan 14 17:00:39 Tower root: plugin: creating: /usr/local/emhttp/plugins/intel-gpu-top/README.md - from INLINE content
Jan 14 17:00:39 Tower root: plugin: running: anonymous
Jan 14 17:01:37 Tower nginx: 2022/01/14 17:01:37 [error] 5342#5342: *1368254 open() "/usr/local/emhttp/plugins/dynamix.system.stats/images/sys.png" failed (2: No such file or directory) while sending to client, client: 192.168.177.109, server: , request: "GET /plugins/dynamix.system.stats/images/sys.png HTTP/1.1", host: "192.168.177.2", referrer: "http://192.168.177.2/Stats"
Jan 14 17:01:42 Tower emhttpd: read SMART /dev/sdd
Jan 14 18:01:48 Tower emhttpd: spinning down /dev/sdd
Jan 14 19:02:20 Tower rpc.mountd[5244]: authenticated mount request from 192.168.177.4:684 for /mnt/user/Aufnahmen (/mnt/user/Aufnahmen)
Jan 14 19:02:40 Tower rpc.mountd[5244]: authenticated mount request from 192.168.177.4:978 for /mnt/user/Aufnahmen (/mnt/user/Aufnahmen)
Jan 15 01:00:54 Tower rpc.mountd[5244]: authenticated mount request from 192.168.177.4:865 for /mnt/user/Aufnahmen (/mnt/user/Aufnahmen)
Jan 15 03:39:55 Tower emhttpd: spinning down /dev/sde
Jan 15 03:39:55 Tower emhttpd: spinning down /dev/sdb
Jan 15 03:40:01 Tower root: mover: started
Jan 15 03:40:01 Tower root: mover: finished
Jan 15 11:49:05 Tower kernel: microcode: microcode updated early to revision 0xea, date = 2021-01-25
Jan 15 11:49:05 Tower kernel: Linux version 5.14.15-Unraid (root@Develop) (gcc (GCC) 11.2.0, GNU ld version 2.37-slack15) #1 SMP Thu Oct 28 09:56:33 PDT 2021
Jan 15 11:49:05 Tower kernel: Command line: BOOT_IMAGE=/bzimage initrd=/bzroot
Jan 15 11:49:05 Tower kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
Jan 15 11:49:05 Tower kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
Jan 15 11:49:05 Tower kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
Jan 15 11:49:05 Tower kernel: x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers'
Jan 15 11:49:05 Tower kernel: x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR'
Jan 15 11:49:05 Tower kernel: x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
Jan 15 11:49:05 Tower kernel: x86/fpu: xstate_offset[3]:  832, xstate_sizes[3]:   64
Jan 15 11:49:05 Tower kernel: x86/fpu: xstate_offset[4]:  896, xstate_sizes[4]:   64
Jan 15 11:49:05 Tower kernel: x86/fpu: Enabled xstate features 0x1f, context size is 960 bytes, using 'compacted' format.
Jan 15 11:49:05 Tower kernel: signal: max sigframe size: 2032
Jan 15 11:49:05 Tower kernel: BIOS-provided physical RAM map:

 

 

Mit neuem Stick Trotz Backup jammert er jetzt "Die registrierte GUID stimmt nicht mit dem USB Flash Bootgerät überein"

Edited January 15, 2022 by Cupra-Bo

[jj1987]

1 hour ago, Cupra-Bo said:

Mit neuem Stick Trotz Backup jammert er jetzt "Die registrierte GUID stimmt nicht mit dem USB Flash Bootgerät überein

Damit hat er ja auch Recht. Du nutzt jetzt ja einen anderen USB Stick.

Aber eigentlich sollte da auch ein Pop-up sein, mit dem du die Lizenz auf den neuen Stick übertragen kannst

[Cupra-Bo]

Habs hinbekommen jetzt ist der alte stick halt gesperrt -.- aber naja ist halt so ... glaub trotzdem nicht daran das es jetzt besser wird

 

EDIT: Was ich gerade noch sehe .. ich hab das USB Plugin damit ich sagen kann dieses USB device direkt zur VM usw .. Also oben im Menü den USB TAB wo auch ein Fehler angezeigt wird!

 

 

 

Edited January 15, 2022 by Cupra-Bo

[mgutt]

Bis 03:40 Uhr, also dem Neustart, waren die Logs ja identisch. Ich mein du kannst das ja ausprobieren. Führe noch mal das tail Kommando aus und dann zieh den USB Stick raus. Mal sehen ob dann auf der SSD noch Logs landen.

[mgutt]

12 minutes ago, Cupra-Bo said:

Also oben im Menü den USB TAB wo auch ein Fehler angezeigt wird!

Schon dazu recherchiert? Ist ja irgendwas von diesem Plugin.

[Cupra-Bo]

5 minutes ago, mgutt said:

Bis 03:40 Uhr, also dem Neustart, waren die Logs ja identisch. Ich mein du kannst das ja ausprobieren. Führe noch mal das tail Kommando aus und dann zieh den USB Stick raus. Mal sehen ob dann auf der SSD noch Logs landen.

 

Das ist klar weil dein Befehl ja nach nem neustart nicht mehr Greift .. hab das aber jetzt mit dem neuen Stick wieder gemacht .. und werde das jetzt mal beobachten und einfach wieder Laufen lassen

 

4 minutes ago, mgutt said:

Schon dazu recherchiert? Ist ja irgendwas von diesem Plugin.

 

Negativ ist mir gerade erst aufgefallen das er hier nen Fehler schmeißt

[Cupra-Bo]

Ich meld mich auch mal wieder .. will hier jetzt nichts Beschreien aber ein Bild sagt mehr als Tausend Worte nach dem USB Stick Switch

 

 

[mgutt]

On 1/22/2022 at 4:26 PM, Cupra-Bo said:

nach dem USB Stick Switch

Und läuft immer noch?

[Cupra-Bo]

Sorry das ich mich jetzt erst melde

 

Hab jetzt mal wieder die anderen Ram Riegel reingeballert und was soll ich Sagen die Kiste rennt immer noch  im moment 7 Tage scheint echt so als wenn ich die Ganze Aktion Rechner wechsel usw wegen nem Neuen Defekten Stick gemacht hab -.-

[Cupra-Bo]

Heute nachts war ma wieder so weit ca4 uhr crash Log wie immer nix auffälliges

 

Letzten zeilen vor Crash

Feb  9 03:40:02 Tower root: mover: started
Feb  9 03:40:02 Tower move: file: /mnt/cache/3D-Drucker_und_FPV/3D Drucker/KlipperScreen_Android Device.pdf
Feb  9 03:40:02 Tower root: mover: finished
Feb  9 03:40:12 Tower emhttpd: read SMART /dev/sde
Feb  9 03:40:12 Tower emhttpd: read SMART /dev/sdb
Feb  9 03:40:30 Tower emhttpd: read SMART /dev/sdd

 

[DataCollector]

Hallo @mgutt

On 1/12/2022 at 7:10 PM, mgutt said:

Mach mal bitte folgendes:

tail -f /var/log/syslog > /mnt/cache/syslog.txt & disown

Damit wird alles, was in die syslog geschrieben wird, parallel auf deine SSD geschrieben.

Frage: Da ich meinen USB Stick nicht unbedingt kaputt-/vollschreiben will, kann man unraid auch beibringen Syslog immer auf einen Array oder Pool (Cache/SSD) zu schreiben?

Das würde den empfindlicheren Stick schonen und mit etwas tricksen kann man das Systelog ja auch dort auslesen (wnen etwas nicht so gravierendes schief geht).

 

Hintergrund:

Ich habe vor kurzem beim Mover das Logging mal eingeschaltet und am folgenden Tag dadurch gemerkt, daß ich einen blöden Fehler gemacht habe ('Prefer' hatte ich gesetzt anstatt 'Yes' und dadurch hat der Mover versucht meine 350 TB Nutzdaten auf meine 2TB NVMe Cache SSD zu quetschen 😅).

Fix Common Problems hat mich auf das Syslog mit 100% hingewiesen (ich verstehe zwar nicht, wie diese 100% Angabe berechnet wird, da der Stick selber noch viel freien Platz hatte) aber das ist zweitrangig.

Doch Syslog hat (vermutlich) wegen dem Füllstand von 132.571.136 Byte irgendwann Nachts gegen 23 Uhr mit dem Logging aufgehört. Somit konnte ich keine weiteren Meldungen nach dem Abbruch im Syslog lesen. Ich verspreche mir vom Logging auf eine SSD/Cache/Pool/Share/Array ein größeres Log und weniger Schreiblast auf einem empfindlichen USB Stick.

[mgutt]

1 hour ago, DataCollector said:

Da ich meinen USB Stick nicht unbedingt kaputt-/vollschreiben will

Ich frage mich immer wieder, wie das eigentlich gehen soll. Die Datei darf max 128MB groß werden. Dann ist die im Dashboard auf Maximum und sollte ja eigentlich beim Nutzer ein "was ist da los" auslösen. Bei den meisten ist die kleiner als 10MB. Also wie kann man damit einen Stick kaputt machen?

 

1 hour ago, DataCollector said:

Ich verspreche mir vom Logging auf eine SSD/Cache/Pool/Share/Array ein größeres Log

128MB sind voreingestellt, weil die syslog in deinen RAM geschrieben wird und unRAID daher möglichst wenig Platz verbrauchen möchte.

 

Das Problem bei einem Array oder Pool als Ziel ist, dass das ja nicht ständig gemountet sein muss.

 

Natürlich könnte man das RAM Drive der syslog vergrößern:

https://forums.unraid.net/topic/40227-when-logs-rotate-rsyslog-stop-logging/?do=findComment&comment=394498

 

 

Und du könntest einen local syslog mirror umsetzen:

https://wiki.unraid.net/Manual/Troubleshooting#Persistent_Logs_.28Syslog_server.29

 

Auch denkbar wäre eine logrotate-Regel, welche die auf den Cache kopiert, komprimiert und dann leert. Wenn das interessant ist, müsste ich mir dazu mal eine Regel einfallen lassen.

[DataCollector]

12 hours ago, mgutt said:

Ich frage mich immer wieder, wie das eigentlich gehen soll. Die Datei darf max 128MB groß werden.

ich fragte mich ja schon woran sich die angeblichen 100% orientieren. Es gibt also eine fest vorgegebene maximale Größe.

Danke sehr, das hatte ich in der Doku noch nicht gefunden. Ich arbeite mich da imem rnoch durch.

 

12 hours ago, mgutt said:

Dann ist die im Dashboard auf Maximum und sollte ja eigentlich beim Nutzer ein "was ist da los" auslösen. Bei den meisten ist die kleiner als 10MB. Also wie kann man damit einen Stick kaputt machen?

Da ich nicht wusste, daß es eine maximale Größe gibt (und wo die liegt), hatte ich eben befürchtet, daß es unter ungünstigsten Bedingungen zu endlosem Schreiben bis an die Kapazitätsgrenze des Sticks kommen könnte. Wenn das zu oft passiert 'verschleißt' man eben die Flashzellen, da in USB-Speichersticks überwiegend die minimalste Qualität an Flashspeichern verwendet wird.

 

12 hours ago, mgutt said:

Natürlich könnte man das RAM Drive der syslog vergrößern:

...

Und du könntest einen local syslog mirror umsetzen:

Danke sehr!

 

12 hours ago, mgutt said:

Auch denkbar wäre eine logrotate-Regel, welche die auf den Cache kopiert, komprimiert und dann leert. Wenn das interessant ist, müsste ich mir dazu mal eine Regel einfallen lassen.

Die Mühe musst Du Dir nicht machen.

Aktuell reicht mir Deine Antwort als Beruhigung und Erklärung, warum die Syslog Datei auf einmal av´bends nicht mehr weiter loggte.

 

[Cupra-Bo]

Da die kiste gerade mal wieder gedacht hat ich frezz einfach mal hier meine Liste

 

15.01.2022 5:23 uhr Crash ->> USB Stick Gewechselt

09.02.2022 ca 4 uhr Crash
10.02.2022 22:46 Uhr Crash
26.02.2022 22:10 Uhr Crash

 

ist besser seit dem Wechsel aber nicht weg -.-

 

Wollte evtl noch mal nen anderen Stick testen am liebsten ohne viel mit Atkvieren rumzumachen

 

Ist es möglich Test lizens und dann backup einspielen das die gleichen settings alles wieder da ist ?

Edited February 26, 2022 by Cupra-Bo

[alturismo]

7 hours ago, Cupra-Bo said:

Ist es möglich Test lizens und dann backup einspielen das die gleichen settings alles wieder da ist ?

 

yep, nur die key file(s) in /config auf dem stick beachten

 

sprich, die vom "alten" Stick nicht mit auf den "neuen" kopieren

[Cupra-Bo]

oki dann werde ich das die woche mal testen hab jetzt mal noch nen neuen stick bestellt

[mgutt]

Langsam würde ich ja aufgeben und quasi alles tauschen. 🤷

[Cupra-Bo]

On 2/27/2022 at 7:19 PM, mgutt said:

Langsam würde ich ja aufgeben und quasi alles tauschen. 🤷

 

Hab schon mit dem gedanken gespielt nen nagel neues Setup zu kaufen .. aber ansich seh ichs nicht ein im moment eh eher schwer

und bei meinem Glück wandert der Fehler mit

[alturismo]

ich hatte auch gerade das Vergnügen ...

 

meine vorherige Hardware wurde wieder für unraid mobilisiert und ist auch einfach nur ausgegangen ... freeze ohne Meldung(en)

 

am Ende war es jetzt die Kombi USB Stick und Sata Kabel, jetzt schnurrt er wieder ...

 

und das Ganze ohne jegliche log Einträge mit Hinweisen zu den Fehler(n) ... nur da ich ja wusste dass da unraid vorher problemlos lief ... hab ich alles zerlegt, wieder zusammen gebaut, dabei auch gesehen dass mein Kollege den USB Stick verbogen hatte (nach der Korrektur USB Stick war der Server im idle wieder stabil), dann immer bei Sata Aktivität der VM crashed, Kabel getauscht, erledigt ... (die cache Platte war noch relativ neu, daher hatte ich auch da einen hardware Defekt mal ausgeschlossen).

 

Viel Erfolg ...

[Cupra-Bo]

danke für den tipp sata kabel könnte ich mal durchtauschen