billington.mark

Members
  • Posts

    362
  • Joined

  • Last visited

Report Comments posted by billington.mark

  1. 4 hours ago, doubleohwhatever said:

    I know this likely won't matter to anyone but I've been using unraid for just over ten years now and I'm very sad to see how the nvidia driver situation has been handled.

    While I am very glad that custom builds are no longer needed to add the nvidia driver, I am very disappointed in the apparent lack of communication and appreciation from Limetech to the community members that have provided us with a solution for all the time Limetech would not.

    If this kind of corporate-esque "we don't care" attitude is going to be adopted then that removes an important differentiating factor between Unraid and Synology, etc. For some of us, cost isn't a barrier. Unraid has an indie appeal with good leaders and a strong community.

    Please understand how important the unraid community is and appreciate those in the community that put in the time to make unraid better for all of us.

    This sums up my stance too.

    I can understand LimeTechs view as to why they didnt feel the need to communicate this to the other parties involved (as they never officially asked them to develop the solution they'd developed and put in place). But on the flip side the appeal of UnRaid is the community spirit and drive to implement things which make the platform more useful. 

    It wouldnt have taken a lot to give certain members in community a heads up that this was coming, and to give credit where credit is due in the release notes. Something along the lines of:

    "After seeing the appeal and demand around 3rd party driver integration with unraid as its matured over recent years we've introduced a mechanism to bring this into the core OS distribution. We want to thank specific members of the community such as @CHBMB and @bass_rock who've unofficially supported this in recent times and which drove the need to implement this in a way which allows better support for the OS as a whole for the entire community, and remove the need for users to use unofficial builds."


    Also for them to be given a heads up and at least involved in the implementation stages at an advisory or review level as well...


    Anyway, I hope this communication mishap can be resolved. It was obviously not intentional, and 2020 as a whole has meant we're all stressed and overworked (I am anyway!), so it makes situations like this a lot easier to trigger.

    Hopefully lessons can be learned here and changes similar to this can be managed with a little more community involvement going forward.

     

    • Like 8
    • Thanks 1
  2. Had the error with a disk not decrypting after shutting down to install an additional NVME.

    Not sure that has any relevance but its a change to the system from the previous boot.

    If memory serves me right, I got the same behaviour when removing an old SSD last time this happened, so it could have something to do with a hardware change from the previous boot, or a disk addition\removal in particular?

     

    1st attempt at starting the array disk1 didn't want to decrypt, although all other disks did. 

    Stopped the array and tried again (no reboot), and disk5 didn't decrypt the second time. All other disks were fine though.

     

    Rebooted and everything is happy again.

     

    Logs attached.

    unraid-diagnostics-20200822-1247.zip

  3. Had to roll back to beta22. Array wouldnt decrypt some drives on starting the array. (got an incorrect passkey error). Odd thing is that each time i stoppped the arrany and tried it again, it would struggle to mount different disks each time.

    Needed to get the array back up asap so it slipped my mind to take logs.

    Is this a known issue?

  4. 8 hours ago, Jerky_san said:

    Yeah I tried a lot of different things.. It doesn't make sense though as the topology fixes were technically in 3.0 so don't understand why I can't let it pass through and instead have to emulate an EPYC which does show the proper topology.

    looks like we're waiting for QEMU 4.0.... https://wiki.qemu.org/Planning/4.0
    I dont think the unraid guys compile from source, they'll just grab the latest stable version... which is currently 3.1 :(

     

    The commits im interested in got pushed after the 3.1 release now ive cross referenced all the dates! :(

     

    @jonpIs there any way we could get a 'bleeding edge' build of QEMU built from the master git branch in the next rc maybe? Being able to test threadripper and PCIe root port lane size fixes would be great :). Looking at the current schedule for 4.0, it looks like we'll be waiting a few months before the next official release.... 

     

     

  5. 7 hours ago, Jerky_san said:

    Updated.. my dreams of having a fixed threadripper cache native supported dashed sadly. QEMU 3.1 doesn't seem to have the fix either.

    Looks like the fun stuff to fix threadripper issues and PCIe Root ports becoming x16 ports is coming in QEMU 4.0 :(. I hope i'm wrong though!

    Did you update your XML to use the new Machine type? 

    Im going to experiment with the PCIe port speed when im home this evening.