phbigred

Members
  • Posts

    265
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by phbigred

  1. You appear to have 16GB of memory in the system assigning 12GB including overhead is why you are at 83% used. Is your jump drive 64GB for unraid? Think that's where your 55GB comes from. 

  2. #1 within a minute or 2 of purchase. You drop your key on the drive and boot up.

    #2 this includes cache, parity, unassigned devices mounting at boot. USB drive for unraid doesn't count. 

    #3 USB 2.0 or 3.0, SanDisk has a good reputation. If you can plug it into a USB 2.0 port on your board. Historically has a better result, but 3.0 is fine. 

    #4 Updates are only manual. You have to initiate them. 

    • Like 1
  3. You could use Krusader docker to move from disk to disk. That's the preferred methodology. Then once you confirm you got off all the emulated data do a new config making sure to note which serial number your parity drive is.

  4. Getting odd logs and a D3 reset error since upgrading to Ryzen 3000. Now throwing code 127's when passing through the Phison controller.

     

    Jan 1 16:41:00 unraid-box kernel: vfio-pci 0000:32:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=none
    Jan 1 16:41:00 unraid-box kernel: nvme nvme0: failed to set APST feature (-19)
    Jan 1 16:41:00 unraid-box kernel: vfio-pci 0000:32:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=none
    Jan 1 16:41:00 unraid-box kernel: vfio-pci 0000:01:00.0: Refused to change power state, currently in D3
    Jan 1 16:41:00 unraid-box kernel: nvme nvme0: pci function 0000:01:00.0
    Jan 1 16:41:00 unraid-box kernel: nvme 0000:01:00.0: Refused to change power state, currently in D3
    Jan 1 16:41:00 unraid-box kernel: nvme nvme0: Removing after probe failure status: -19

     

    Thoughts on a solution? I'd love to get my system back functional with NVMe passthrough, having to use an old image on a sata based SSD currently.

     

     

    unraid-box-diagnostics-20200101-1649.zip

  5. Quick question, were there changes in this build that affected the br0 settings with VMs? I can't isolate out VPN vs no VPN traffic without using the local client now. Used to just add the IPs to an alias list that routed it on the individual br0 IPs. Pfsense gateway routing used to work for unraid now doesn't function unless I remove the unraid server IP from the VPN.

     

    For clarification I haven't tested against the Limetech build as I just figured this out yesterday. Might be worth some testing.

  6. CRC errors may be nothing more than a loose cable. The drive that died might be the same thing.  Are you by chance using onboard connections that might be Marvell controllers? New board new connections might be something as simple as that.

  7. 1 minute ago, Frank1940 said:

    The UDMA CRC  errors are not a disk problem in 99.99% of the cases.   They are a transmission of the serial data failure between the disk drive and the SATA controller where the data is converted back into parallel data.  The data stream is sent with a check sum and if that check sum test fails the data is resent.  However, they do slow down disk operations because the correction process suspends further transfers until the error is cleared. 

     

    I am assuming that the reallocated Sectors are very recent.  (These sectors themselves are not a problem because they will never have data stored on them again!)   If they are recent, they could be an indicator that the disk is entering a period of slow decline toward failure.    

    Good point with the crc. I'd say Op go with your best judgement. 

  8. Both are going to take time. Turn off anything that could be writing to the array. Pop out the parity and get that swapped. Order another drive to have on standby. Worst case you have a parity drive you can use for recovery should things go belly up. That's the route I would suggest. 

  9. If you have a prompt login and type diagostics just to capture a log.

     

    First step shut down and reseat all cables. The drive dropping off may have had a similar problem. You mention an lsi card is it seated properly in the mini sas connection? May be worth finding out if your motherboard has Marvell controllers. Having this much weirdness at once makes me think whatever the data connections are being driven from is having a problem with unraid. Rerun the data cables/swap. I'll leave it for the more experienced to give more ideas. Also to be sure you aren't having any brownouts correct? Hopefully using a UPS of some sort.

  10. https://wiki.unraid.net/Shrink_array

    You can shrink your array, I've done it as few times. If you are looking to reduce the count of disks go with a single parity. Remember it has to be = or greater than the largest drive. Word to the wise... If you are thinking of encrypting later on, you may want to do it from the beginning as in-place encryption isn't available yet. Also confirm your nvme drives aren't using a Marvell controller, known issue with Linux.