Magmanthe

Members
  • Posts

    37
  • Joined

  • Last visited

Everything posted by Magmanthe

  1. So I'm back with an update.. Since yesterday, I came back from work today to check the Rebuild-progress, and lo and behold the "unresponsiveness" is back. System is all locked-up (both from WebGui) and from direct-connected mouse/keyboard/screen. However instead of hard-resetting and turning the system off/on at the current time, i will leave it on until tomorrow morning (Friday) just in case the actual parity and disk-rebuild is still going on in the background. From experience I know it should take around 1 day and ~3-5 hours, and I started it at around 22 yesterday.. So around midnight tonight (if it is still going) it will be done. However it does not seem that the RAM-sticks are at fault then, as I now have 4 fully functional sticks from what I tested yesterday. any particular BIOS-settings that might interfere? (I remember reading about AMD and C-states that might make the system unresponsive , but I'm running Intel so it shouldn't be that). Other HW-issues like a MB error perhaps? I turned CPU-graphics on in Bios due to locally connected screen via HDMI (or maybe it was DP; but anyway, directly to the I/O of the MB), with a mouse/keyboard. the screen there is also "stuck" on the log-in screen (as you can see) and after it locked-up (sometime during the night, or during daytime when I was at work) that too, becomes unresponsive.. Any halp is appreciated //Magmanthe
  2. Rebuild in progress.. Now we play the waiting game Thanks a bunch for the input and help, @trurl much appreciated...
  3. Yeah, no I don't take them physically out of the server.. I remove them "softwareliy" from the array when it is stopped, start the array. Then i stop the array again, and add it back in. Okay, so that's how I have been doing it before too, so I know how to do it.. However, earlier it was always only 1 disk that was "lost" (disabled). and it was also not a parity disk, so rebuilding it was not an issue. Now it is a parity disk and and regular. do I build them back into the array at the same time, or take 1 disk at a time? //Magmanthe
  4. Hi again, So I've now run MemeTest on all 4 sticks, and wouldn't you know... 1 of them was really bad. 3 passed fine without any errors, but the last is garbage as you can see from the pix.. Luckily I did have a spare so no biggie.. So thanks for pointing me in that direction much appreciated.. Didn't think of that at all.. However when starting the server now, the Parity 1 disk and Disk 1 is still marked as disabled for some reason.. Anything else I can do? //Magmanthe
  5. Okay. But for all intents and purposes there is nothing wrong with doing it, as long as the include and exlude-rule don't overlap. but let me ask you then. If audiobook is set to include disk 3. and disk 3 is full, what happens when I shove in MORE audibooks? Which disk does it begin to put that data into? Chronologically the first disk? the next disk in line after Disk 3? None, as I set include disk 3 and thus if full, it just discards the data? //Magmanthe
  6. quick update.. i know to check sticks separetly, but did a quick-check with all 4, and it spit out errors (just as a sanity check).. So there is for sure something wrong with one (or more), so I'll pull the sticks and check them one-by-one.. Thanks for the tips, didn't even consider it to be a RAM-error... //Magmanthe
  7. Yeah, I am aware of the inc/exlude, but that is also a bit of the OCD that I am forcing specific data onto specific disks without any possible spill-over. So i will respectfully disagree that there are scenarios where you use both include and exlude. But this is also besides the point. Disk-inclusion or exslusion for certain shares, does not have anything to do with a locked-up system with disk falling out of the array? (assumption) No, have not run memtest.. maybe I give it a whirl and see what it spits out. I'll come back in a few days after MemTest is finsihed. //Magmanthe
  8. Well that depends on your setup, doesn't it? Cause I'm using auto-login with FTP and Keyfile and the full FTP-adress/username/PW is in there as well.. So you know, not overly enthusiastic for the whole world to see that 'll delete the Go-file and add the ZIP magnas-diagnostics-20210505-1455.zip
  9. I know you said to add the full zip, but I see there are plaintext PW's in there in the Go-file, so you ain't getting that file from the config-folder. Any other files that might have plaintext-identifiable info that I will remove? //Magmanthe
  10. Hey, So I have this weird-issue that usually happens around the Parity-check and or reboot of server. Yesterday this happened again, I upgraded the server to 6.9.2 (but this has been with the machine for a while, so it has nothing to do with 6.9.x). I upgraded and after that I rebooted the server. Server spins up again nicely, and logs in as normal. Then after a few minutes (maybe an hour), it becomes totally unresponsive. playing files from the server does not work, accessing it via file-explorer does not work, WebGui unresponsive, as locally connected screen/mouse/keyboard also becomes completely unresponsive. Only "solution" I have found is a hard-reboot, pressing the reset-button the the chassis. Then once the server turns back on, what happened previously was that one of the disks fell out of the array. Red X in the Main-screen with "Device is disabled, Contents emulated". This happened to my smallest Disk 4 and my workaround to deal with this was just to stop array, take out the disk, start the array. Stop the array again, include the disk and rebuild it. Now yesterday this happened again after the update, but when I reboot the server now, it is no longer my Disk4 that fell out, but my Parity 1 and Disk 1 doing this, which is weird, cause that's new. I have activated the syslog-server from Settings, but that log is worthless, it only says May 4 20:39:38 magnas /dev/log [info]: Server is up! /var/run/unraid-api.sock May 4 20:39:45 magnas /dev/log [info]: Server is up! /var/run/unraid-api.sock May 5 11:37:10 magnas /dev/log [info]: Server is up! /var/run/unraid-api.sock May 5 11:37:16 magnas /dev/log [info]: Server is up! /var/run/unraid-api.sock May 5 13:33:42 magnas /dev/log [info]: Server is up! /var/run/unraid-api.sock May 5 13:33:48 magnas /dev/log [info]: Server is up! /var/run/unraid-api.sock Any help for how to find out what is actually happening here would be much appreciated. Where can I find more detailed logging of what is going on? //magmanthe