matt4542

Members
  • Posts

    4
  • Joined

  • Last visited

Everything posted by matt4542

  1. I am well aware of this, I have read the post and I've watched their YouTube video. It's not a change of functionality for "legacy" users but it's the idea that was sold to the users. It's changed, it's different, and that product is no longer available. How does that guarantee availability in the future? It truly does feel like a switch. Companies that have historically offered legacy perpetual license support when changing licensing models generally slowly fade it away as it's nowhere as lucrative as the subscription. Again, it's a Trust Us™️ scenario.
  2. So you've moved to a subscription model and are just telling everyone else Trust Us™️ who owns a now "legacy" key? This is a switch on the people who have purchased your software, which inherently leads to distrust and how can I trust going forward you'll honor your claims? Switching to a subscription model in any way shape or form leads to a loss in customer. I've been having people build unRAID arrays on suggestion for years, but I'll be moving away due to this announcement and will suggest others do the same. Such a shame, unRAID is an easy tool but it's nowhere near the only game in town.
  3. Hi all, This is a long one that I've been digging into for an extensive period of time. I have a headless unRAID server that had two failing drives, 5x4TB with 4 in array and 1 as parity. Order 16TB drives, and the day prior to going to perform the install and migration, the server was unexpectedly inaccessible via the browser. I attempted a reboot of the server, which successfully brought it back online. Shut it down, installed the new drives, and began a parity rebuild with the new 16TB installed. This completed successfully, but shortly after, the server went offline again. Dug around, and found that the GPU was returning errors. Pulled the GPU, and the issue then again happened. Due to the disks being in poor shape, and needing to move the data quickly, I began to do small transfers of the data to the larger disks and worked around the server going offline until successfully transferring all data off the failing disks (~1500 relocated sectors, and getting worse, so needed to act fast). Started digging into syslogs after reboots, and syslogs showed that unassigned devices was throwing errors every few seconds. I disabled all system plugins, removed them across the board, and the issue persisted. Since I wasn't finding much, I went and enabled a write to boot for the syslogs and was able to identify a CPU microcode error that was being throw. Dug into it, and found that this can occur with the BIOS version I had, the 3rd revision from release for a Ryzen x370, so not surprising. Performed upgrades on the BIOS until I reached the latest, but the issue occurred yet again. Digging further, I found that when the server goes "offline", the issue only seems to be hitting the device over the network. If I boot GUI mode, it's still accessible via the unRAID server's direct console, and the unRAID server can ping outbound, but I cannot ping the unRAID server from another device on the network. I found an error being thrown by the system that the DHCP lease renewal had failed after identifying the seemingly network related issues, and disabled my DHCP reservation in favor of a static IP. The issue happened again. I then set another static IP, and the issue again returned. After not being able to resolve from a network standpoint, I ran a memtest86 which immediately errored on 3/4 of my DIMMs. I went and purchased replacement memory and tested it completely (full 10 tests, 8 passes) and it came back clean. After ~36hrs, the server went down again, rinse and repeat. I continued digging, and upon online research I learned that C-States can cause an issue with unRAID and the early generation Ryzen processors, which I have a 1600x powering my server. I disabled C-States in the BIOS completely, and the issue persisted. In an attempt to replicate the issue, which I was unable to do so far, I ran prime95 on the system to try and stress the CPU and see if the issue occurs. It did not, I ran prime95 for hours with no issue or hitch (issue usually occurs with 30m-2hrs of boot, but can take up to a day and a half). Upon attempting the memory test, it exists almost immediately. I attempted several times, after numerous reboots, and each attempt to run prime95 involving the memory whatsoever fails to run and exits in ~20-30 seconds. Doing research, this can be indicative of a bad memory controller. I ran memtest86 again, which came back perfectly clean. Saw online that a reseat of the CPU may resolve issues with a memory controller, due to a poor seating/pin connection, so gave this a try but no luck and the issue returned. In all of this, my unRAID USB drive became corrupted and I had to restore from backups (My Servers coming in clutch) to get the server back up and running, so unfortunately I only have syslogs from the past few days to share. The syslog shared includes reinstalled plugins that I used to assist in troubleshooting so far, once that were originally removed after confirming they were unrelated to the issue. I'm at a loss at this point, outside of replacing the CPU and motherboard, which I'd rather not do. This was an otherwise stable and reliable system up until ~3 weeks - 1 month ago. Any guidance or suggestions is greatly appreciated. syslog.txt nas-diagnostics-20230313-1921.zip
  4. Thanks for this, Juan. You set me on the right path. I also saw your comment on the Github issues page for the vnc-version only working with Catalina. I dug around a bit and have a working docker run command that seems to be working. I'm currently installing Ventura using VNC without having to manually build the image. This looks to have done it for me. docker run -i \ --device /dev/kvm \ --device /dev/snd \ -p 50922:10022 \ -p 8888:5999 \ -v /tmp/.X11-unix:/tmp/.X11-unix \ -e "DISPLAY=${DISPLAY:-:0.0}" \ -e EXTRA="-display none -vnc 0.0.0.0:99,password=on" \ -d --privileged \ sickcodes/docker-osx:ventura