-
Posts
362 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Report Comments posted by billington.mark
-
-
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.
-
1 hour ago, limetech said:
no
re-updated and its behaved this time. i'll grab logs if it does it again.
-
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?
-
On 5/3/2019 at 5:25 PM, limetech said:
Why?
So docker images can make use of iGPU transcoding.
-
Is it possible to enable the AMD APU iGPU Drivers in this build somehow? @eschultz
-
Any chance of having QEMU from the master branch rather than 3.1 in the next release?
Or, can these patches be applied: https://patchwork.kernel.org/cover/10683043/
-
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.1The 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....
-
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.
-
Changed Status to Solved
-
Can confirm this is resolved in 6.6.2
Thanks all :)
-
Also, behavior is the same in safe-mode boot
-
Xorg log(s) attached. its just creating these over and over again. I assume every time the screen refreshes (as shown in the original post)
-
No change. regardless of legacy or UEFI boot.
-
Also, if someone can post (or PM if its not allowed) a direct link to the 6.6rc1 download, (as i dont have access to an unraid GUI), that would be very useful!EDIT: got the URL out of the plg
Unraid OS version 6.9.0-beta35 available
-
-
-
-
-
in Prereleases
Posted · Edited by billington.mark
more words
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.