hawihoney

Bin nur mit Smartphone im Hotel deshalb nur kurz. IPMI hat wirklich nix mit dem Ganzen zu tun. Wenn dann wirklich nur das MB oder Unraid bzw. dessen Linux Unterbau oder die installierten Plugins. Als neugieriger Mensch würde ich folgendes testen: 1. Unraid 6.10.3 im Maintenance Modus, also ohne Plugins, starten und gucken was passiert. Irgendwelche zusätzlichen Kommandos in der go Datei vorher auskommentieren. 2. Wenn dann trotzdem der Sensorwert hoch geht, dann hat sich m.E. im Kernel etwas geändert bzgl. der Sensoren. 3. Wenn der Sensorwert nicht steigt, dann fummelt ein Plugin etwas an den Sensor Einstellungen rum. Etwas anderes kann es m.E. nicht sein. Eine Distribution wie Unraid ändert doch nicht an so was rum. Die haben genug zu tun. Ich habe meinen CPU Fan Sensor im IPMI anpassen müssen damit IPMI auf Grund dessen geringer Umdrehung nicht permanent Fehler auswirft. Diese Einstellung ging über das IPMI Tool und die macht man einmal und das war's. Das es beim Hin- und Her-Schalten zwischen zwei OS Versionen diese Wechsel gibt habe ich noch nie gesehen. Hat noch jemand dieses MB?

Mach doch bitte Mal einen Screenshot von den IPMI Anzeigen mit 6.9.2 und 6.10.3. Ich kann das echt nicht glauben. IPMI ist absolut losgelöst vom OS.

Nur damit ich das verstehe: Die Anzeige der Card Side Temp (i.d.R. Oberseite des MB) in der IPMI Konsole ändert sich signifikant zwischen 6.9.2 und 6.10.3? Ich meine wirklich die IPMI Oberfläche und nicht Sensoren oder Plugins in der Unraid Konsole oder Oberfläche. Das würde mich völlig verwirren. Was hat IPMI/BMC mit Unraid zu tun? Wenn es wirklich durch das IPMI selbst anders angezeigt wird, dann kann es ja nur eine veränderte Nutzung unter 6.10.3 sein. Wie sind die NVMes denn eingebunden? ZFS, BTRFS, XFS? Welche RAID Konfiguration? Etc.

Habe u.a. die o.g. Links gefunden.

@nixweis Hab den Film mit Usenet Explorer gefunden. Mir ist jetzt auch klar warum der bei meiner ursprünglichen Suche nicht auftauchte. Alles unter 1 GB ignorieren meine Tools Und da das ein Kurzfilm ist, flutschen dessen 384 MB einfach durch. Danke für den Tipp.

Hat vor einiger Zeit stark abgebaut und ist nur für ca. 2-3 Jahre Retention gut. NZBKing ist da besser. Den Chaplin kannte ich noch nicht. Den finde ich bei meiner Suche nicht. Viele warnen vor Momentum. Was sein kann, dass die sich bei anderen Quellen wie oben beschrieben bedienen und den kryptischen Header des Original Uploads Dir anbieten. Das ist jetzt aber nur eine Vermutung. Denn z.B. Eweka hat über 4000 Tage Retention und löscht nicht. Selbst da ist der Titel nicht zu finden. Gerade die alten Sachen konserviere ich mir sehr gerne. Spannend finde ich die Szene die aus amerikanischem Video Material (z.B. Bluray) und deutschem Ton (z.B. DVD) eine neue Bluray dubben die es so nicht in Deutschland zu kaufen gibt. Da ist etwas entstanden - digital sei Dank - dem ich höchsten Respekt zolle, selbst im Wissen, dass es illegal ist. Wenn schon bei "Vom Winde verweht", je nach Sender, Warntafeln vorgeschaltet werden, da wünscht man sich doch glatt eine Sammlung, die noch unzensiert/unmodifiziert ist und es bleibt.

Eigentlich müsste in der Nextcloud Konsole "occ maintenance:repair" ausreichen. Das "sudo -u abc php" ist meines Erachtens nicht notwendig.

Für mich sind so gut wie alle Usenet "Programme" völlig überladen und unübersichtlich. Ich nutze für uralt Content (über 4000 Tage Retention) eine lizenzierte Version des UsenetExplorers. Aber auch bei dem finde ich mich einfach nicht zurecht und nutze nur die NZB Erzeugung für NZBGet. Newsleecher, BinSearch und wie sie alle heißen - meiner persönlichen Meinung völlig überfüllt mit Optionen. Ist aber wie bei Word und Konsorten: 95% der Benutzer kommen mit 5% der Funktionen aus. Nur 5% der Benutzer benötigen einen Teil des restlichen Funktionsumfangs von 95%. Links zu Programmen, auch weiteren, habe ich oben gepostet. Persönlich nutze ich zu 99,99% NZBGet. Für mich ist NZBGet eine der stabilsten, zuverlässigsten und komfortabelsten Anwendungen die ich je benutzt habe.

Alles klar, hatte Dich falsch verstanden. Das muss natürlich in der MariaDB/mySQL Konsole gemacht werden. Aber das hat der OP schon gefunden.

Du meinst, dass das nicht geht: mysqld -u root -p --tc-heuristic-recover=ROLLBACK -p erzwingt die versteckte Eingabe des Passworts und da müsste der Inhalt von MYSQL_ROOT_PASSWORD rein. Bin unterwegs, kann gerade nicht an die Kiste.

Die Ausgabe von mysqld wundert mich, denn genau so habe ich es vor einigen Jahren, beim bisher einzigen Crash, noch machen können. Ich habe das Dokument mit dem passenden Skript eben nochmal aus dem Archiv geladen. Seltsam. Gut, man pappt jetzt noch -u mit dem User/root und -p ohne weitere Angabe dazwischen, gibt das root Passwort auf Nachfrage an und gut ist.

Zunächst wird zwischen der Karte mit 2GB RAM und der Karte mit mehr RAM unterschieden. Da gibt es schon mal einen Unterschied. Weiterhin kann man den Wert "patchen". Aber von Hause aus kann die Karte nur das was in der Support Matrix steht. Transcoden wird durch NVENC unterstützt (encoden). Decoden durch NVDEC. https://developer.nvidia.com/video-encode-and-decode-gpu-support-matrix-new#Encoder

Falsch, so funktioniert das nicht. Zunächst muss die Platte ermittelt werden. Das ginge nur mit der von mir erwähnten zusätzlichen Binär-Operation die das fehlerhafte Bit ermittelt und an Hand der Bit Position die Platte im Array ermittelt. Erst danach kannst Du mit der Sektornummer auf der erst danach bekannten Platte die Inhalte des Sektors ermitteln. Unraid liest beim Sync von allen Platten die Inhalte an der gleichen Bit-Position und gleicht das Ergebnis mit der Parity ab. Besteht dort ein Unterschied, dann weiß Unraid zunächst nur, dass es an der Position x (im Sektor y) eine Differenz gibt. Unraid kennt also immer den Sektor des Fehlers, aber nicht die Platte des Fehlers. Genau bei einer solchen Diskrepanz müsste Unraid mit einer zusätzlichen Operation das fehlerhafte Bit ermitteln und darüber die Platte. Erst dann könnte es theoretisch weiter gehen. Die Diskussion lässt mich vermuten, dass Du die Parity Kalkulation nicht ganz verinnerlicht hast: https://wiki.unraid.net/Manual/Overview#Parity-Protected_Array 1.) Nehmen wir an Du hast 3x Datenplatten und 1x Parity. Und das wäre der Inhalt der drei Platten an Position x in Sektor y. Dann wäre das Ergebnis aus den 3 Nullen ebenfalls 0 (ja ist denn schon wieder Karneval). Das Ergebnis 0 liegt in der Parity dann an der selben Position x. Platte1=0 Platte2=0 Platte3=0 -> Parity=0 2.) Nun hast Du einen Crash und der darauf folgende Parity-Check findet aber etwas anderes vor: Platte1=0 Platte2=1 Platte3=0 Parity=0 An dieser Stelle weiß Unraid zunächst nur, dass es an Position x im Sektor y eine Differenz gab. Mehr ist noch nicht bekannt. Um das transparent zu machen, muss das erst aufgelöst werden. Das macht Unraid aber nicht. Beim Durchlesen der verschiedenen Wiki Einträge bin ich auch etwas ins Grübeln gekommen. Einmal ist von XOR die Rede und einmal von Summen. Hmm, ich tue mal so, als wäre es XOR. Wenn Du nun also wissen willst welche Position die besagte 1 hat müsste nochmals XOR ausgeführt werden. Dann bleiben alle identischen Positionen 0, nur die Differenz bekommt eine 1. Damit erkennst Du dann das fehlerhafte Bit an der zweiten Stelle, was dann zur Datenplatte #2 führt. Und jetzt packst Du das gesamte Wissen aus Platte und Sektor zusammen und ermittelst den Inhalt. P.S.: Da hole ich doch mal gleich mein allererstes EDV Buch aus dem Schrank (1980), das ich aus Nostalgie behalten habe, und was finde ich auf der letzten Seite? Binär Operationen handgemalt in meiner Schrift aus den 20ern Was für ein Zufall. Damals schrieb ich an meiner ersten kommerziellen Kauf-Software in Assembler Z80 (Zilog). War kein Kracher, aber hatte wenigstens in ein paar Zeitungen zu einer Erwähnung geführt.

Solange sich dieser Wert nicht verändert, würde ich die Platte weiter betreiben. Sie hat eigentlich gesunde Werte (100/200).

Wenn es nicht zu klären wäre, dann würde ich einen backup.sav Ordner anlegen und die Inhalte von backup dort reinschieben. Dann würde ich mal ein paar Wochen abwarten. Du scheinst ein Backup Tool zu nutzen: https://github.com/nextcloud/backup

Ich lösche im "/mnt/pool_nvme/system/appdata/nextcloud.data/updater-octcdtkazv4p/backups" Verzeichnis alte Backups. Bei mir sieht das aber anders aus als bei Dir. Immer nur Full Backups ausgelöst durch Upgrades. Wo kommen die differential Dinger her? Wie entstehen diese Backups.

Das hatte ich oben geschrieben. Unraid müsste eine zweite Binär Operation nachschieben und könnte das falsche Bit ermitteln. Die Bit Position ist dann die Position der Disk im Array. So weit die Theorie. Allerdings kenne ich nicht die exakte Vorgehensweise. Arbeitet Unraid tatsächlich mit 32 Bit (meiner Meinung nach der Grund für das Plattenlimit) in einer Operation oder mit irgendeiner mir unbekannten Bulk-Operation (z.B. sektorweise).

Bei mir kracht Unraid nie runter. Und Verzögerungen im Shutdown habe ich bisher immer gefunden (100% offene Sessions). Beide Male war es ein wackelnder HBA - das erste mal nach dem Eintreffen meines zweiten Servers aus den USA (von LimeTech) und das zweite Mal nach einem Umzug (2009). Ich fummele halt nicht an funktionierenden Systemen rum. Müsste eigentlich mal einen BIOS Update machen (bei einem Reboot fehlt immer die selbe NVMe, bei einem Shutdown und Reboot nicht). Den Update schiebe ich wahrscheinlich auf ewig vor mir her. Nein. Ich habe einfach alle Dateien die rund um den Sync Error erstellt bzw. geändert wurden geprüft. Es waren beim ersten Mal 1408 Fehler (hat sich bei mir eingebrannt). Zu prüfen waren ziemlich viele Dateien. Das meiste war Content den ich auf Verdacht einfach wieder besorgt habe. Kenne ich nicht, aber ehrlich. So ein Tool ist pillepalle. Eine SQLite Db, ein Skript welches Hashes erzeugt, in der Db speichert und in ihr abgleicht. Ermittlung obsoleter Dateien. Speichern der Durchläufe. Und Pause/Resume bei Belastung des Systems. Ich hätte so ein Tool schon längst gebaut wenn ich es selbst nutzen würde. Darüber hinaus würde ich drei Monate Prüflauf oder so nicht wollen (Belastung, Strom, ...).

Du sagst es ja häufiger selbst: Software ist nicht so Deins. Du bist doch gut in Hardware. Hab gerade ein Problem mit meiner Klimaanlage. Ich hoffe Du verstehst meinen Vergleich. Habe mein ganzes Berufsleben Software gebaut. Aber das ist ein gigantisches Feld. Da spezialisiert man sich. Mit dem Auftauchen von OS/2 1.1 haben mein Partner und ich uns die Felder aufgeteilt (er Netzwerk und Kommunikation, ich Datenbanken und GUI. Davor haben wir beide alles betreut und entwickelt). Die Spezialisten sind tief im Kernel etc. Wenn die etwas nicht zur Verfügung stellen, dann kann der Rest der Entwickler nichts machen. Zudem bin nach wie vor der Meinung, dass die Ausgabe von Dateien und Ordnern beim Parity Check irrelevant ist. Heutzutage haben Dateisysteme Transaction-Logs (wie Datenbanken). Die reparieren sich bereits auf dieser Ebene selbst. Da die Parity kein Log pflegt, hat, wie ich oben schon schrieb, die "selbstheilende" Datenplatte Vorrang - das ist aber nur ein Grund von mehreren. Außerdem: Vermeide halt die vielen Crashes 😁 Das war nicht meine Frage. Du hättest gerne Ordner bzw. Dateien benannt. Wie Du siehst macht das meines Wissens kein Parity- bzw. Sync Tool. Was mag denn wohl der Grund sein? Setz bei Bedarf einfach Deine Hash-Tools ein. Hatte in nun 14 Jahren mit Unraid 2x Sync Errors - beide Male Hardware. Seit dem Rausschmiss von BTRFS gibts auch keine ausfallenden NVMes mehr bei mir. Spiel halt nicht so viel an den Kisten rum 😉 Nachtrag: Bei meinen Sync-Errors bin ich über das Datum der Dateien an die Kontrolle der Dateien gegangen.

Das habe ich auch nicht angedeutet. Nur wie Unraid das für jedes verwendete Dateisystem ermitteln kann, wird wohl nicht öffentlich zugänglich sein - denke ich mal. Ist auch nicht Unraids Aufgabe, ganz andere Layer sind da im Spiel. Ja, durch die FS Entwickler. Wenn es aber keine Tools von denen gibt, dann steht man da. Wie ist das eigentlich bei den klassischen RAID Systemen. Schreiben die Ordner bzw. Dateien bei einem Fehler raus?

Dual Parity. P+Q. Nennt man so. Nachtrag zur Recherche: Zunächst einmal ist das vom Dateisystem abhängig - die Du ja im Array fröhlich mixen kannst. Dann wird ja nur festgestellt, dass der kalkulierte Wert der Datenplatten nicht zur Parity passt. Datenplatten haben dabei Vorrang, also wird die Parity überschrieben. Willst Du dann wissen was sich an der Stelle geändert hat, müsste Unraid mit einer weiteren Binäroperation feststellen, welche der Datenplatten abweicht. Und dann springt noch die Verschlüsselung in den Weg. Das ist Forensik. Würde mich wundern wenn die Methode für jedes Dateisystem irgendwo frei verfügbar ist.

Offensichtlich landen Deine Daten in Deiner Windows VM (in der Image Datei). Plex erzeugt trillionen Metadaten-Dateien. Wenn die alle in der VM landen dann wäre das unausweichlich. Guck Mal wie groß die Image Datei ist und der Füllstand.

Für appdata/domains --> Cache Prefer Für normale Daten --> Cache yes Du nutzt für Deine Container zwei verschiedene Angaben durcheinander (/mnt/cache vs. /mnt/user). Das würde ich konsequent entweder auf eines oder das andere setzen. Traditionell /mnt/user. Ist der Mover bei Dir aktiviert?

Hä? Ich nutze 6.10.3. Ah, erst hieß es kaputt, jetzt heißt es per klick. Was kommt als nächstes? Es ist hier im Forum bestimmt ein dutzend mal beschrieben, wie man als Betreiber eines Unraid Servers den Conbee2 Stick in eine VM bekommt: Ausführen: ls -la /dev/serial/by-id/ In VM Konfiguration aufnehmen: <serial type='dev'> <source path='/dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_********'/> <target type='usb-serial' port='1'> <model name='usb-serial'/> </target> <alias name='serial1'/> <address type='usb' bus='0' port='4'/> </serial> Fertig! So sieht das dann in der Home Assistant/Deconz Konfiguration aus und ist sofort einsatzbereit: Jetzt bin ich aber wirklich raus hier.

Nutzung von ungenutztem RAM für Verzeichnisstrukturen und Dateidetails bzw. -fragmenten macht Linux unter der Haube - und das sehr gut. In dem Sinne gibt es aus Linux Sicht kein ungenutztes RAM. Was Du nicht nutzt schnappt sich Linux und pagt lustig damit rum. Die paar GB sind wirklich nicht die Rede wert um damit etwas Zusätzliches anzufangen. Du kannst die tmp Deiner Container darauf umbiegen oder gleich ganze appdata Inhalte. Dann musst Du Dich aber selbst um das Synchronisieren kümmern. Mit RAM Disks, etc. habe ich seit dem letzten Jahrhundert nicht gearbeitet, da das Standard Ressourcen Handling einfach nur noch schwer zu toppen ist. Aber damals gab es auch RAM Kompressoren ... Linux und deren Ableger funktionieren am besten wenn wir Laien nicht daran rumfummeln. Ist so als pappst Du einen Spoiler an ein Neufahrzeug, welches während der Entwicklung tagelang im Windkanal war ...