MAM59

Zwischenbericht nach 3 Tagen (ohne Startupgruppen): Platte 4 geht immer noch ordnungsgemäß in Standby :-) Warten wir nochmal 3 Tage, dann kann man wohl mit an Sicherheit grenzender Wahrscheinlichkeit sagen, dass der Bug irgendwo in den Startupgruppen liegt...

Basically you have two configs that are fighting constantly who will be honored first. ETH0 and tailscale. both claim the rights to modify /etc/resolv.conf, so dnsmasq restarts every minute. turn off tailscale (for whatever it is good for???) and you should be done with the problem.

Ach DU warst das !!!🤣 (Scherz) Na ja, mit dem Alter schwinden Augen und Ohren, deshalb spar ich mir Atmos, die 5.1 Anlage ist abgeschaltet, ne schnöde Soundbar reicht nun. Die Nachbarn (nächstes Haus) haben die 2*300W Sinus Subwoofer nicht vermisst :-) Die Boxen hängen zwar noch im Wohnzimmer unter der Decke und in den Ecken, aber sind nicht mehr angeschlossen. Und "scharf" war eh gestern, meine Augen sehen keinen Unterschied zwischen 2k und 4k mehr. Also hab ich pragmatisch abgerüstet.

Na ja, Jellyfin streamt und hat die lokale Kontrolle über die benutzten Daten. Mein Kodi ist autonom und greift über SMB auf die einzelnen Shares zu. Ich bin kein Freund von Streaming, erstmal leidet die Qualität u.U. dramatisch, zweitens wird reichlich Energie beim Encoden verbraten. Ich encode einmal in ein geräteübergreifendes "MAM-Format" (*) (das sich im Laufe der Jahre schon mal ändern kann), welches ALLE Player abspielen können. Somit kein Bedarf an dauerndem Umkodieren. (Ausserdem ist der Platzbedarf um den Faktor 2-3 geringer :-) ) Nur vierstellig? Du Glücklicher :-) ich bin bei Filmen 5 stellig, bei Serienepisoden schon fast im 6 stelligen Bereich... Eben "70 Jahre Jäger & Sammler" :-) (*) = derzeit 1920x1080x25 H265 mit Dolby Digital 5.1 oder AAC Stereo. Ausnahmen sind in 4k, ältere HD Filme in 720p (werden ausgetauscht mit der Zeit), ein paar SD Leichen finden sich bestimmt auch noch irgendwo, aber wenn entdeckt, wird getauscht

Na ja, da sind verteilt Filme, Serien, Actor Pics usw drauf. Es ist etwas nervig, wenn man im Mediaplayer (Kodi) rumscrollt und dauernd bleibt er hängen, weil die jeweilige Platte erst hochfahren muß. Besonders die Akzeptanz von FRAUEN leidet darunter enorm. Also, alle auf einmal anwerfen, FRAU erziehen zu "beim Start kann es zu einer Pause von bis zu 30s kommen" und RUHE haben :-)

ich auch, wobei es nun deutlich schwieriger ist, das Problem zu erkennen, da man ja nie sagen kann, wann eine Platte im Schlafmodus sein sollte. Das fiel nur auf mit der Spinup Gruppe, da alle aus waren, nur die nicht.

Hmm, gute Frage, ich kann die Gruppe ja mal löschen und rebooten... dann dauerts wieder ein paar Tage und wir werden sehen. Oder soll ich den jetzigen Zustand erstmal beibehalten? Meine Hoffnung war ja, dass der fehlerhafte Status ein zufälliges Ereignis war und dass man dann später mit hdparm manuell (nach einmaligem Fehler probiert UNRAID es ja nie wieder) erzwingen kann. Aber, wie man sieht, trotz "OK" fährt die Platte nicht runter :-( Ist ja kein Beinbruch, im Notfall kann ich damit leben. Update: Dank fortgeschrittenem Alter ist die verbleibende Lebenszeit zu wichtig, um sie mit Warten zu verschwenden :-) Ich hab also die Startupgruppen deaktiviert und die Kiste neue gebootet (nun mit spindown auf 15min). Mal sehen, was passiert und wenn ja, wann...

So, nach 5 Tagen war es wieder so weit, disk 4 "klemmt" :-( Here we are again, after 5 days the drive is "stuck" again :-( Ich hab versucht, die spindown befehle von Hand zu geben, sie werden alle kommentarlos akzeptiert, aber die Platte fährt nicht runter. I have tried the spindown commands manually. All return 0 exit status, the drive does not spindown. root@F:~# /usr/sbin/hdparm -C /dev/sdf /dev/sdf: drive state is: idle root@F:~# /usr/sbin/hdparm -y /dev/sdf /dev/sdf: issuing standby command root@F:~# echo $? 0 root@F:~# /usr/sbin/hdparm -C /dev/sdf /dev/sdf: drive state is: standby root@F:~# echo $? 0 root@F:~# /usr/sbin/hdparm -S0 /dev/sdf /dev/sdf: setting standby to 0 (off) root@F:~# echo $? 0 root@F:~# Was nun? What to do next?

After running it monthly for a year or so, I have set it to quarterly now since 3 yrs. No errors until now. Having 2 parity drives in an array is too much I think. Disk failures today are luckily unfrequent statistically so having one fallback drive is usually enough. Maybe if you have 20+ drives in your array, 2 parity drives would be a good idea though still not needed.

I don't like "AI assisted development" too, even it is hip these days. AI may help you to find certain functions or structures to use, but I never would let it write full code for me. It would take longer to check it than to write it myself. And I have seen a lot of "AI-generated-mistakes" already. So, if the community rules are "no AI", don't complain, just obey. (And yes, "30 years" is nothing, you youngster 🤣 I did not count really, but I guess, I am over 50yrs now already... or maybe a little less...)

Maybe a wrong descion, it will depend on my test soon to come (after the drive is locked again soon)

It is even more wierd. The disk "works" for some hours, even days obeying spinup and spindown commands. But suddenly it reports back status 1 (not supported). From then on, UNRAID does not even try anymore to spin it up or down. THAT is the main problem, it is locked until reboot. When it happens next time I will try manually the hdparm commands for spinning up and down and see, if status 1 keeps on, or if it was as wrong reading somehow.

Also ich bin nun etwas weiter: nach einem Reboot kann man die Platte 4 wieder "runterfahren" aber irgendwann kommt dann bei sdspin der returnwert 1 und ab da ist die Platte "blockiert" Es geht also ein paar Stunden/Tage gut, danach klemmt die Platte. Die Frage ist: "Was is returnwert 1 bei SDSPIN?" Fazit: sobald einmal 1 kam, wird die Platte nie wieder angefasst von sdspin. Das muss also irgendwo gespeichert werden bis zum Reboot Da SDSPIN nur ein Skript ist, war die Lösung einfach: "1" bedeutet "unterstützt wahrscheinlich kein standby". Das ist aber in diesem Falle ein Fehler. Ich warte mal ab, bis es wieder passiert, und probiere dann mit hdparms direkt. Vielleicht kommen da sinnvollere Hinweise bei heraus

Son Hexenwerk gibts hier nicht, alles schnödes SATA. Ach ja, ich sollte was anhängen, wobei, da findet sich kein Hinweis auf eine mögliche Ursache... Wobei, selbst wenn man manuell versucht, diese Platte runterzufahren, /dev/sdf taucht noch nichtmals in der Versuchsliste im Syslog auf :-( f-diagnostics-20260715-1803.zip Wobei, bei genauerer Durchsicht fällt mir folgende Zeile auf: Jul 8 12:00:22 F emhttpd: sdspin /dev/sdf up: 1 Vorher hat er noch sdf erfolgreich runtergefahren, danach irgendwann wieder hochgefahren, und als Ergebnis kam obiger Eintrag. Was immer das bedeuten mag (für andere Laufwerke finde ich solche Zeilen nicht)

Mein Problem existiert schon ewig, aber bislang hat niemand eine sinnvolle Idee geschweige denn Abhilfe geschaffen :-( Also starten wir nochmal einen Versuch: alle Array Platten sind in der Startup Gruppe "Array" mit einem Timeout von 30min. Nach 30min Inaktivität fahren auch alle brav herunter und sparen Strom. Alle? Nein, EINE Platte bleibt standhaft und läuft weiter: Aus unerfindlichen Gründen mag Platte 4 nicht schlafen gehen, auch von Hand kann man sie nicht dazu bewegen. Ja, ich weis, "da wird irgendein Task eine Datei blockieren", die Standardantwort. Aber, da ist nix besonderes drauf: Und "Openfiles" zeigt auch nichts auf Disk4 Egal was ich mache, Disk4 bleibt immer an :-( SNIEF! (wenn man die Startdup Gruppen deaktiviert, KANN man Disk4 runterfahren !) Also, da ist echt der Wurm drin, wo ist der Siegfried, der diesem Lindwurm den Garaus macht???

It MIGHT kill your docker because the routes are different to the services. Disable either in UNRAID (network config) or switch it off in the BIOS (the logs show that docker is started, maybe it is unreachable because of wrong network config)

hmm, nothing special found but: lo UNKNOWN 127.0.0.1/8 ::1/128 tunl0@NONE DOWN eth0 UP wlan0 UP 192.168.0.201/24 metric 3004 bond0 UP br0 UP 192.168.0.200/24 metric 1 shim-wlan0@wlan0 UP fe80::50bb:b500:112:31ab/64 wg0 UNKNOWN 10.66.236.68/32 docker0 DOWN 172.17.0.1/16 tailscale1 UNKNOWN 100.XXX.XXX.16/32 fd7a:115c:a1e0::3739:1211/128 fe80::b680:21d4:c09d:4084/64 You try to put br0 and wlan0 into the same subnet 192.168.0.*. This cannot work! they will fight for the connections and it is unpredictable who wins (and may even change after reboots). Disable wlan0 (or put it into a different subnet) and reboot.

to have a chance to get a "more than guessed" answer, you should supply diagnostics

Wierd setup you have... anyway... just install "unassigned devices" plugin and it will show you both NVMes One of them will be mountable, the other seems to have no valid filesystem This will be the former parity drive. (still dont understand why someone uses two nvme drives within an unraid array (no TRIM support!!!) and uses one as data the other for parity. The more common approach would be to create a mirrored zfs pool, but again.. it is your choice.)

Ok, dange :-) Noch ein Grund mehr, NIX zu ändern 😁 Ich wundere mich nur, was die Leute hier für einen Aufwand betreiben mit gespiegelten ZFS Pools usw. Ist doch Banane, zumal die Lizenz ja nun im TPM steckt. Aber egal, soll sich jeder so kompliziert gestalten, wie er will, auch wenn es keinerlei Nutzen hat.

hmm, ich kann da nur raten (benutze die "neue" Bootmethode nirgends, mein Vertrauen ist da nicht so ausgeprägt...), aber, so wie ich das verstehe, gibts keine RAM Disk mehr bei "neuem Boot", oder nicht? Insofern wäre das Laden und Entpacken nach von bzroot&Co nur der Anfang des Updates. Danach müsste ja noch eine Stage folgen, wo die dann entpackt werden und auf die SSD(s) gespeichert werden. Aber, wie gesagt, ich habs nie ausprobiert und werde es wohl auch nie.

2 Unraid Licenses, 1 active, one for testing only 1 backup server (Windows) 1 Freebsd Server (Mail, Homepage and a lot of network stuff) (*) 1 Windows PDC (just for DNS, MS-DNS is so easy to handle, no match in the *nix world) (*) (* these are Mini PCs with 2*10G and 2*2.5G LAN interfaces, power consumption <15W each)

hmm, das wird dann wohl "/data" sein... (oder das ist der Pfad zu den Quelldateien?) Üblicherweise gibt Dir ein Hover mit der Maus oder ein Aufruf von "Edit" mehr Infos zum Sinn der Einstellung (hoffentlich :-) ) ) Musstest Du in dem DuploDingsDa irgendwo den Zielpfad unter /data einstellen?

na ja, was fehl schlägt, ist das Lesen der Originaldaten. "Zugriff verweigert" bei Appdata usw. Guck Dir mal die Dateiberechtigungen da an und wem sie gehören. Eventuell läuft der Backup Docker mit dem falschen Benutzer und darf nicht an die Daten ran (und was man nicht lesen kann, darf man auch nicht kopieren...) Es gibt zwar unter Tools den Knopf "Docker save Permissions", aber der sorgt öfters für noch mehr Ärger. Also lieber von Hand gucken und ggf, korrigieren.

No, I've meant it the other way round. IF you have cache dirs installed AND you are low on memory, THEN there might be a chance of "lost files" (not actually lost on disk but not shown in "dir-like" commands because the cache was full and the file entry did not make it into the list anymore) So my advice was intended to tell you "if you are running 'cache dirs', deinstall it and see if things change". "cache dir" speeds things up a lot, so many people are using it.