JustinChase Posted April 15, 2015 Share Posted April 15, 2015 I tried playing a file from my media server inside my Windows8 VM, it hung solid, and I tried to force restart the VM; it hung, and eventually hung the entire server. I hard booted, and now I'm seeing this error in the GUI. I assume I can shut down, remove the USB, put it in a windows box and repair it; but is there any other way to 'fix' this without resorting to that? My USB is mounted inside the case, so I'd rather not have to open it. Link to comment
RobJ Posted April 15, 2015 Share Posted April 15, 2015 Most likely, you are going to have to repair it on another station, but check the syslog first, for errors related to sda. The message isn't completely clear as to why it's not read/write. Link to comment
trurl Posted April 15, 2015 Share Posted April 15, 2015 I have not tried this myself, but see here Link to comment
jeffreywhunter Posted April 15, 2015 Share Posted April 15, 2015 I had a problem like this a couple days ago. Just put the USB into my Windows PC and ran makebootable.bat again. Might not be the same as yours. I had inadvertently (or perhaps absent mindedly) pulled the USB from a running system to pull a log and put it back, then pre-clear couldn't write logs out! Duh. Running makebootable.bat fixed it... Link to comment
JustinChase Posted April 15, 2015 Author Share Posted April 15, 2015 Well, I just rebooted to see what would happen, and it rebooted fine, but has started another parity check. no obvious signs of USB problems yet but it seems I didn't see that error until parity check finished last time (from memory). We'll see tomorrow morning how it looks. Link to comment
trurl Posted April 15, 2015 Share Posted April 15, 2015 Well, I just rebooted to see what would happen, and it rebooted fine, but has started another parity check. no obvious signs of USB problems yet but it seems I didn't see that error until parity check finished last time (from memory). We'll see tomorrow morning how it looks. Did you stop the array before rebooting? If not then that is why you got another parity check. If you did stop the array before rebooting, then the fact that you got another parity check anyway means your flash is not writable. unRAID saves the started/stopped state of the array on the flash, and if you stopped the array but unRAID could not write to the flash, then it would have no way of knowing that the array was stopped when it started the next time. Link to comment
JustinChase Posted April 15, 2015 Author Share Posted April 15, 2015 I did stop the array before rebooting. the USB was definitely NOT writable when I stopped it (the reason for stopping it), so I'm not surprised it couldn't read the status when it started again. I guess I'll see what happens when it finishes Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.