dojesus

Members
  • Posts

    27
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

dojesus's Achievements

Newbie

Newbie (1/14)

1

Reputation

  1. It was a royal pain rolling it back to 6.8.3 after having upgraded to 6.9.0, then 6.9.1. I may be adding a pcie card to the mix next weekend. I may just jump to 6.9.1, get the crash download the diagnostic, and roll back to 6.8.3...if y'all want me to do that to help discover what the problem is.
  2. Perhaps my older logs are still there, but I only had today to roll back and finish parity sync. *edit* I did back up my flash drive before rolling back....would the appropriate info be contained in that backup? tower-diagnostics-20210321-1821.zip
  3. I'm running an x570 board. Was waiting on 6.9.0, so I could pass through my onboard audio to VM, as it would lock up the server on 6.8.3. After upgrade, audio IS being passed through, but random VM crashes followed. Every CPU core and thread (including the isolated ones), would max to 100% same for RAM usage, and everything would become unresponsive until the VM would crash, then the resources are restored to the server. I upgraded to 6.9.1 to see if this would resolve the problem...it didn't. There is something very wrong with the new kernel drivers, IMO. I've been forced to roll back to 6.8.3, due to failing WAF. If you need anything from me that would help track down the issue, I'm happy to oblige.
  4. Hmm....I did watch the video, but I didn't see the part where it said I was to edit the script. Which part am I editing?
  5. Thanks! I found them and added them manually, however, after running the helper script, it didn't generate the VM. What am I missing?
  6. User scripts didn't install....any idea why? And can you post the actual scripts so I can add them manually?
  7. Final update on this issue. Clearly the problem was/is hardware related, as the parity drives are disabling again in 6.8.2. Not sure why they work so long before the issue returned, but it's NOT the software. Ordered a new SAS controller, to replace the failing onboard controller, which will tide me over til my AMD upgrade later this year. Thank you everyone for your help and advise.
  8. Except it's not happening in 6.8.2....which is why I'm having a hard time wrapping my head around what the problem is. I see that 6.9 is the same code as 6.8.3 with an upgraded kernel. I expect this problem to return when I try RC1, as it's unlikely the new kernel will "fix" the issue.
  9. Makes sense. Thanks for the response, trurl. Does 6.8.3 have any type of "sleep" commands that would shut down the SATA controller, that would fail to "wake up" on a write? I'm trying to wrap my head around how docker or plugin upgrades would trigger this weird disabling.
  10. Will do. Is there an approximate time frame?
  11. Well, I've been running the same gear since Jan. 2016. The only issues I've had were the database corruption one that kept me on 6.6.7 for quite some time and this one from 6.8.3. Can you think of a non-software related thing that would make both drives drop out, when they work fine on 6.8.2? I'm open for testing to help prevent future problems.
  12. Just a follow up...It's been a week since I've rolled back to 6.8.2 and have done numerous updates and the parity drives aren't dropping out anymore. There is clearly something wrong in the 6.8.3 update that is negatively affecting the Asmedia sata controller....at least my revision of it. I'm hoping a dev sees this, as it may be a minor problem now, but it could snowball into something worse down the road on later updates.
  13. I'm guessing the parity drives rarely spin down, is that incorrect? Why both parity drives on the same backplane as all other drives, that are the only drives disabling? Are they doing something profoundly different that would cause both to stop, or the controller to fail, after a docker update?
  14. Thanks for looking at the log. I did, but could make sense of it. Well, I've been running the same system for 4 years and the controller may be going away....but I kind of doubt it, since it goes back to operating fine after restoring drives and parity rebuild. The failures ONLY come after I updated to .3 and I update a docker or plugin. I rolled back to .2 and will monitor and report back if it stays working or not. Thanks again. *edit* Sorry, missed your question. All drives are on a common backplane on a Silverstone CS-380. Only 2 power legs feeding 8 drives. If it were a power issue, I would lose, at least, 4 drives at once, I would imagine. Since they were only the parity drives and different MFGs that dropped, it seemed to likely be software related. I was one of those bitten by the database corruption bug and stayed at 6.6.7 for a long time. When I did upgrade to 6.8.2, it was smooth sailing, no issues. This happen after my first docker update after upping to .3. It could be coincidental, but I have my doubts and I guess running it back on .2 for a while will prove it, one way or another.
  15. For the 3rd time in 2 weeks since updating 6.8.2 to .3, both of my Parity drives disable at the same time. Both 6TB, 1 WD and 1 HGST to prevent batch issues. Is this a known issue and is there a fix? I saved my diagnostics, but have rolled back to 6.8.2, to see if the update is the issue. Kind of a pain that I spent 2 1/2 days rebuilding my parity drives, only to have them disable again after updating my dockers and plugins. tower-diagnostics-20200516-1837.zip