gnollo
-
Posts
687 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by gnollo
-
-
I stopped the array anyway, unassigned the disk and restarted. Although content is emulated, I cannot get to disk2 as I usually do via \\tower\disk2.
And now I get read errors from disk7, which is not on the same norco unit that was affected before.
-
The array has already started, and the drive is already emulated. Do you want me to stop the array first, then unassign the disk and restart?
-
I agree, something affected that Norco controller, power likely. I doubled up now on power connectors for each of the two Norco's 500 now.
What do I do with the disabled drive? I had to do an unclean shutdown as the tower would not stop. DId that cause filesystem corruption?
-
-
Array started with disk 2 disabled.
Not sure what to do next, I don't want to lose any of the data on disk2
Sent from my SM-A520F using Tapatalk -
Rebooted, used two molex for each Norco cage this time.
Disk2 unmountable, no file system
Sent from my SM-A520F using Tapatalk -
-
Things have gone a lot worse since the parity check.
I could not connect to the network drives so I logged on the Unraid Gui
- 1 drive disabled (drive2)
- 2 other drives with errors
- emby server stopped
- parity has over three and half billion errors
- CPU almost at 100%
- tried to stop the array but it's stuck on "stopping"
- wont' shut down, even with telnet connection and poweroff
The one thing that the affected drives have in common, is that they all reside in one of the Norco SS500.
I am only using one power connector for all the three norcos in use, should I change that?
Also in that norco connector, I have a drive (parity) which I had to tape on one of the power connectors to allow for unraid to recognise it upon booting (I took it out of an external drive cage).
Diagnostics attached. I am thinking hard poweroff at the mains, swap power connector on the affected drive, and reboot.
I think rebuilding drive 2 is very dangerous, as I don't feel I can trust parity. I am more inclined to try to force the system to mark all the drives as good and recalculate parity from scratch (not sure how to do that though).
The problems continue it seems on my server.
-
Also I was still running the emby docker which would have impacted performance, will turn that off next time as I am running parity check
-
4 minutes ago, johnnie.black said:
They won't help, were so many errors expected?
I have no idea, drive 7 was disabled at one point, and I will have done changes to the drives, so perhaps the corrections are to reflect that that drive did not change? Will do another check in a week and see how that works out in terms of number of sync errors.
-
Last time I checked parity in 2019:
Event: Unraid Parity check
Subject: Notice [TOWER] - Parity check finished (47 errors)
Description: Duration: 21 hours, 50 minutes, 34 seconds. Average speed: 101.8 MB/s
Importance: warning -
Parity check completed
Total size:10 TB
Elapsed time:2 days, 1 hour, 27 minutes
Current position:10.0 TB (100.0 %)
Estimated speed:45.0 MB/sec
Estimated finish:completed
Sync errors corrected:488083827
Speed a bit on the low side, perhaps because of the number of sync errors?
-
1 hour ago, gnollo said:
Emby server is not running though. It looks like is trying to run 3.5.3.0
Fixed that too. Deleted library.db and now it's up and running
-
Emby server is not running though. It looks like is trying to run 3.5.3.0
-
Booted fine with new configuration, running parity check now. Two drives (including 7) now show UDMA CRC error counts (4 and 55).
-
It booted but it has the wrong configuration of drives, as it predates my update of parity to a bigger drive.
I guess i can stiill do a new config and then run a parity sync/check?
-
Mmmh. Turns out it's not strictly a flash problem. Copied the backed up contents from the flash that is failing to boot over to the flash that booted, and that also now is exhibiting the same issue of looping booting.
So I created a new fresh install of unraid plain config on the original flash that failed yesterday, copied across the permissioning key alone, and it boots fine.
Now I will try to copy across the last version of the flash I saved in December, and see if that works too.
-
It seems to be a flash problem. Formatted another flash with rufus and installed a fresh copy of unraid server, it boots with no issues.
Inserted the current flash in my laptop, it found errors, I scanned and fixed it but it still doesn't work.
Copied off all the files I could see after the fix, and now I am reformatting it with rufus, unticked fast format, now it's taking ages.
This must be connected with the messages about the flash being unreadable in the past, but it was rebooting fine and the message was appearing only from time to time. I guess I should have listened and replaced the flash straight away?
-
Now I have a different problem. Removed the drive after stopping and starting the array, and rebooted, and the booting process goes in a loop.
I can see the usual process flashing by (PCI Devices listing...) until the line "SYSLINUX 6.03 EDD ...." appears on the screen, then it flashes back to the boot screen and starts again a few times, then the process stops at that line, and I have to hard reboot (CTRL/ALT/DEL does not appear to work anymore).
Why o why did I move that drive. Why...
-
Drive was fine but now it has been disabled because of read errors after moving it to another slot in my norco caddy. I moved the drive after stopping the array, but not turning off the system.
Is there a way to tell unraid to enable it without having to rebuild it?
Diagnostics attached.
-
Here is an example of the two MD5 numbers being different for the same mkv full rip of the bluray (Dark City).
I used MakeMKV to build the file on the old drive, and parity rebuilt it on the new drive.
-
I am still unable to run rsync on a folder with spaces in it. Anyone has any idea other than using the TAB key on how to run it on a folder that is not named as a single word (TAB autocomplete does not work for me for some reason)?
I run the Checksum Compare app from a windows machine, scanning the same folder with spaces ("bluray full rips" on both drives (old and rebuilt) and it says it has found three files that are different.
The are three large mkvs, tested them all three and they play all the way to the end. Could the files that parity recreated be corrupted and still work?
-
Thank you all, I checked the entire bluray folder, took over 10 hours but completed fine finding no files that were different. I will check the other folders as well so I can wipe the data off the old drive and retire it once confirmed.
-
It explains. I just used checksum compare and it tells me everything is ok, the files are identical (as I recreated them using parity). Tried it again with the end / and no incremental file list is showing
[SOLVED] Drive disabled after moving to a different slot
in General Support
Posted
tower-diagnostics-20200529-1303.zip