February 26, 20188 yr I just upgraded one of my backup servers from 6.4.0 to 6.4.1. For the first time in several updates the time for a parity check has gone up: Just FYI; it's only 4.5%. Edited February 26, 20188 yr by bobkart
February 26, 20188 yr An open question here is how much of this that is caused by the Meltdown/Spectre fixes in the kernel.
February 27, 20188 yr Apparently, there are a fair number of users who have Ubiquiti routers in the Community. These routers have the DNS rebinding blocked by default because it can be a security issue. Without this ability, you can not get a Let's Encrypt SSL certificate to give secure access to the server. While this protection can be turned off and the command to do it is shown in the Help for the SSL Certificate Settings page in the Identification tab where you do the provisioning, the Command Line Interface for these routers is quite intimating. I was doing a bit of research and reading and found an easier way to enable the DNS rebinding for the unraid.net website on the less expensive Ubiquiti routers. You can find the instruction here: https://lime-technology.com/forums/topic/61265-what-router-are-you-running/?page=3&tab=comments#comment-637221
February 27, 20188 yr 17 hours ago, bobkart said: I just upgraded one of my backup servers from 6.4.0 to 6.4.1. For the first time in several updates the time for a parity check has gone up: Just FYI; it's only 4.5%. Yep, mine increased as well the first time on 6.4.1. It went from a longstanding average of around 15 hr. 53 min to 16 hr. 25 min. on an 8TB parity drive. It's only an increase of a little more than 3% in my case, but, it's the first time it has ever exceeded 16 hours. I assumed it had something to do with the recent kernel changes, but, it's a small enough disparity that there could be another explanation. I suppose it will take a few more parity checks to see if this is the new norm for my system. I am not too worried about an additional 30 minutes.
February 28, 20188 yr On 2/6/2018 at 8:39 AM, ryoko227 said: Not sure if it is unRAID specifically or the uefi bios loading it there, but efifb is being loaded into the same piece of memory that the primary slot GPU was trying to request. Running bios and unRAID in legacy mode fixed this issue for me as efifb is no longer being loaded. I did a quick write up over here detailing the journey, www. Hope this is helpful for someone, or that maybe the LT guys can take a look into it. I know this is ancient, but I have a startup script that runs echo 0 > /sys/class/vtconsole/vtcon0/bind echo 0 > /sys/class/vtconsole/vtcon1/bind echo efi-framebuffer.0 > /sys/bus/platform/drivers/efi-framebuffer/unbind As a solution to the efifb problem on my machine, then I still have EFI boot.
February 28, 20188 yr On 2/23/2018 at 8:11 PM, GreenDolphin said: Opinions will vary on this... First, I would personally not use any Threadripper CPU on a production server. The product line is far too new (<6 months since launch) for software written for it to be considered stable, which is a prime goal of any server implementation. Ditto for that matter for any other Ryzen CPU -- the architecture is too new. While I agree for production server use, he seems to be looking into running multiple gaming VMs, so for that TR works fine, I use it to host my daily driver with 0 issues since the PCI reset bug was fixed. If it crashes once or twice a year he probably doesn't care too much.
March 1, 20188 yr @GreenDolphin thanks for the advice. I might just change the board and processor in this machine and go cheap on this first build as I get familiar with unRaid. If in the future I decide to upgrade to another box, does moving the hdd's and the unRaid usb into the new machine just work plug-n-play or are there steps to take before migrating your drives to completely new hardware?
March 9, 20188 yr I just saw this error on my log, please see the screenshot. I can upload the log file if needed.
March 9, 20188 yr 6 hours ago, sakh1979 said: I just saw this error on my log, please see the screenshot. I can upload the log file if needed. That's a hardware error, check the board's system event log int the bios/ipmi as it might contain more info.
Archived
This topic is now archived and is closed to further replies.