burtjr

Members
  • Content count

    312
  • Joined

  • Last visited

Community Reputation

4 Neutral

About burtjr

  • Rank
    Advanced Member

Converted

  • Gender
    Male
  • Location
    San Diego

Recent Profile Visitors

119 profile views
  1. I would use it as a cache drive for dockers.
  2. Update the firmware on the SASLP. The last I looked and it was a while ago was up to .21. I don't have the SS-500, I have IStar's, but they worked flawlessly on the SALSLP with the .21 firmware.
  3. The wiki is updated by anyone not Lime Technologies. If you have time put the information together and update the wiki. There is a thread all be it rather long that should give you what you need to get a Ryzen build going. I haven't kept up to date on the 6.4 testing on the Ryzen platform, but was thought to fix some major issues.
  4. Personally I would always attempt merging before upgrading. They will usually get you by and you can determine from there exactly what you will need if in fact you do need to upgrade.
  5. I'm not sure how long you waited for the server to power down, but in my experience it could take hours for it to properly power down because of what ever went rouge to slow down or lock it up. Other than patience and tailing the log to see what caused the server to get to that point I can see that you could have done anything different.
  6. Run fix common problems in troubleshooting mode, then post the logs if/when it happens again.
  7. I found the below in your log, not sure if this would cause your problem, the only other thing I saw in your diagnostic was some warnings in your libvirt.txt file. Although others with more knowledge of dockers and VM's will chime in, I would check your docker and VM set ups, starting with the one using IP address 218.87.108.154 and if they look good to you, shut down all dockers and VMS, check for stability then introduce one at a time until you find the one causing the instability. Jun 1 19:53:00 Tower sshd[14274]: error: maximum authentication attempts exceeded for root from 218.87.109.154 port 52885 ssh2 [preauth] Jun 1 19:53:00 Tower sshd[14274]: Disconnecting: Too many authentication failures [preauth] Jun 1 19:53:02 Tower sshd[14416]: refused connect from 218.87.109.154 (218.87.109.154) Jun 1 19:53:19 Tower sshd[14503]: refused connect from 59.45.175.34 (59.45.175.34) Jun 1 19:53:29 Tower sshd[14545]: refused connect from 116.31.116.39 (116.31.116.39) Jun 1 19:54:03 Tower sshd[14776]: refused connect from 59.45.175.34 (59.45.175.34) Jun 1 19:54:27 Tower sshd[14888]: refused connect from 116.31.116.39 (116.31.116.39)
  8. Think of a VM like a regular computer that your building. If you want to play newer games at the highest frame rates then you buy a top of the line graphics card. In a VM you have a virtual computer using the same hardware as a bare metal box only it's in 1 box and you pass through the card so the VM can use it.
  9. Take a look at the motherboard manual, I think the M2 drive will up a PCIE slot, although not sure which one.
  10. You should read the whole thread, it is a living and breathing document. I think the main fix was concerning the c states.
  11. Looks like disk 1 and 2 have some problems. It would help if you provide a full diagnostic.
  12. You have issues with ATA17 and 18 May 21 04:58:13 Tower kernel: ata17.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen May 21 04:58:13 Tower kernel: ata17.00: failed command: WRITE DMA EXT May 21 04:58:13 Tower kernel: ata17.00: cmd 35/00:58:88:cc:90/00:00:4f:00:00/e0 tag 6 dma 45056 out May 21 04:58:13 Tower kernel: res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) May 21 04:58:13 Tower kernel: ata17.00: status: { DRDY } May 21 04:58:13 Tower kernel: ata17: hard resetting link May 21 04:58:13 Tower kernel: ata17: SATA link up 1.5 Gbps (SStatus 113 SControl 310) May 21 04:58:13 Tower kernel: ata17.00: configured for UDMA/33 May 21 04:58:13 Tower kernel: ata17: EH complete SAMSUNG drive HD204UIe May 20 22:42:24 Tower kernel: ata18.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen May 20 22:42:24 Tower kernel: ata18.00: failed command: READ DMA EXT May 20 22:42:24 Tower kernel: ata18.00: cmd 25/00:08:c8:d9:89/00:00:b1:00:00/e0 tag 30 dma 4096 in May 20 22:42:24 Tower kernel: res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) May 20 22:42:24 Tower kernel: ata18.00: status: { DRDY } May 20 22:42:24 Tower kernel: ata18: hard resetting link May 20 22:42:24 Tower kernel: ata18: SATA link up 6.0 Gbps (SStatus 133 SControl 300) May 20 22:42:24 Tower kernel: ata18.00: configured for UDMA/133 May 20 22:42:24 Tower kernel: ata18: EH complete WD30EZRX-00SPEB0 You have a lot of downloading happening when these errors occurred and ATA:17 continues into a second log. I didn't see anything that stood out in the smart report for these 2 drives. I'll let someone chime in what the DRDY error is, but you could start by doing a clean shutdown and trying to reseat or replace your sata cables to those drives.
  13. I would post this in the nextcloud support thread in the docker container section. You're more likely to get help there.
  14. I just quickly scanned both logs and this stuck out. "FAT-fs (sda1): Directory bread(block 8193) failed" IIn your system flaky, but not in the stable one. 'm not sure if this is causing your instability, but I have linked to a very old thread. While you wait for other more experienced help, you can do a clean shut down and move your USB stick to a different port to see if it fixes the problem. With the operating system loading into memory it seems it seems to be to be unlikely to be causing your problem, but the OS must have to periodically write to the USB.
Copyright © 2005-2017 Lime Technology, Inc. unRAIDĀ® is a registered trademark of Lime Technology, Inc.