[Plugin] Linuxserver.io - Unraid Nvidia


Recommended Posts

The Realtek RTL8125 (driver added in 6.8.0-rc2) does not work on Nvidia Unraid 6.8.0-rc5.

 

I have a full break down of tests and diagnostics over on this thread. Any insight here would be appreciated as I really would like to be able to continue using the Nvidia builds. 

 

The summary is that the RTL8125 works on both stock Unraid 6.8.0-rc5 and rc7 but it fails to work on Nvidia Unraid 6.8.0-rc5.

Link to comment
2 hours ago, wreave said:

The Realtek RTL8125 (driver added in 6.8.0-rc2) does not work on Nvidia Unraid 6.8.0-rc5.

 

I have a full break down of tests and diagnostics over on this thread. Any insight here would be appreciated as I really would like to be able to continue using the Nvidia builds. 

 

The summary is that the RTL8125 works on both stock Unraid 6.8.0-rc5 and rc7 but it fails to work on Nvidia Unraid 6.8.0-rc5.

If it's an out of tree driver, it might be that it didn't build on the nvidia build. I haven't looked at the build at all, so can't say for sure.

It might be a missing dependency or something. This is all "reverse engineered" as we don't get a finished guide from limetech.

Right now the priority is to manage to get the build correct for the latest RC. Your issue might be fixed then also.

  • Like 1
  • Thanks 1
Link to comment
10 hours ago, Riotz said:

Yes please. I am getting tired of the constant reminders to upgrade to RC7. Cant because my PLEX server will lost HW Transcoding.

You should let limetech know about your issues and concerns. After all, it's really limetech who should be providing you with a solution, not a third party like us. We do what we can (chbmb and bassrock put a lot of work into it) but there is only so much an outsider can do when they only have partial info and have to reverse engineer everything.

 

As an example, qnap worked directly with plex employees to make sure their OS included the necessary drivers and packages to make sure transcoding worked with plex on their devices. We are neither the OS provider (limetech) or the client (plex/emby). We're just folks trying to give back to the community.

  • Like 3
  • Thanks 6
Link to comment
19 minutes ago, leejbarker said:

Hi,

 

Completely understand you guys do this in your spare time and I really am thankful for your work so far.

 

I've got a 1650 super recently and I'm just wondering when we might see a driver update...

 

Thanks

We don't gve any time estimate at all. It's released when we get it to work. We are CHBMB and bassrock.

Link to comment
4 hours ago, aptalca said:

You should let limetech know about your issues and concerns. After all, it's really limetech who should be providing you with a solution, not a third party like us. We do what we can (chbmb and bassrock put a lot of work into it) but there is only so much an outsider can do when they only have partial info and have to reverse engineer everything.

 

As an example, qnap worked directly with plex employees to make sure their OS included the necessary drivers and packages to make sure transcoding worked with plex on their devices. We are neither the OS provider (limetech) or the client (plex/emby). We're just folks trying to give back to the community.

100% on this - no real reason this should even exist (so thankful it does) but I am very surprised Limetech isn't looking to pick this up natively.  There is a great use case for Unraid to me

Link to comment

Hello, 

 

I'm having some trouble getting Emby to see my GPU.  I have gone through all the steps, the Nvidia plugin can see my GPU and I've configured the docker container below (binhex-emby).  I've restarted by my entire machine and the Docker container separately, but still no dice.  When I click on the Transcoding page in Emby, and select Advanced, all I see is the section headers.  

 

image.thumb.png.1787eb03e14e22dec13d36cce8dbe009.png

 

Any tips on what I can try to get it to see the GPU?

 

Edit: I see this and a few more errors in my emby docker log: 

Error NvidiaCodecProvider: Error running ffdetect for nvencdec - args: -hide_banner -show_program_version -loglevel 48 -show_error -show_log 40 nvencdec -print_format json

*** Error Report ***

 

Edit2:  I tried setting up the LinuxServer version of the container and though it doesn't show any of the above errors in the log, it also doesn't show anything in the transcode "advanced" page.


Thanks!

dockerlog.txt

Edited by Coolsaber57
Link to comment
On 11/27/2019 at 4:42 PM, aptalca said:

You should let limetech know about your issues and concerns. After all, it's really limetech who should be providing you with a solution, not a third party like us. We do what we can (chbmb and bassrock put a lot of work into it) but there is only so much an outsider can do when they only have partial info and have to reverse engineer everything.

 

As an example, qnap worked directly with plex employees to make sure their OS included the necessary drivers and packages to make sure transcoding worked with plex on their devices. We are neither the OS provider (limetech) or the client (plex/emby). We're just folks trying to give back to the community.

Hi aptalca. Appreciate the work the team does.

I've filled out the contact form on the unraid website and expressed my interest for you guys to get the assistance you need to fix the issue.

Hopefully others do as well.

  • Like 1
Link to comment
On 11/26/2019 at 1:09 PM, wreave said:

The Realtek RTL8125 (driver added in 6.8.0-rc2) does not work on Nvidia Unraid 6.8.0-rc5.

 

I have a full break down of tests and diagnostics over on this thread. Any insight here would be appreciated as I really would like to be able to continue using the Nvidia builds. 

 

The summary is that the RTL8125 works on both stock Unraid 6.8.0-rc5 and rc7 but it fails to work on Nvidia Unraid 6.8.0-rc5.

I think this is resolved, we just need to be able to make the actual Nvidia build work now.  No ETA

  • Like 4
Link to comment

This was an interesting one, builds completed and looked fine, but wouldn't boot, which was where the fun began.

 

Initially I thought it was just because we were still using GCC v8 and LT had moved to GCC v9, alas that wasn't the case.

 

After examining all the bits and watching the builds I tried to boot with all the Nvidia files but using a stock bzroot, which worked.

 

So then tried to unpack and repack a stock bzroot, which also reproduced the error.  And interestingly the repackaged stock bzroot was about 15mb bigger.

 

Asked LT if anything had changed, as we were still using the same commands as we were when I started this back in ~June 2018.  Tom denied anything had changed their end recently.  Just told us they were using xz --check=crc32 --x86 --lzma2=preset=9 to pack bzroot with.

 

So changed the packaging to use that for compression, still wouldn't work. 

 

At one point I had a repack that worked, but when I tried a build again, I couldn't reproduce it, which induced a lot of head scratching and I assumed my version control of the changes I was making must have been messed up, but damned if I could reproduce a working build, both @bass_rock and me were trying to get something working with no luck.

 

Ended up going down a rabbit hole of analysing bzroot with binwalk, and became fairly confident that the microcode prepended to the bzroot file was good, and it must be the actual packaging of the root filesystem that was the error.

 

We focused in on the two lines relevant the problem being LT had given us the parameter to pack with, but that is receiving an input from cpio so can't be fully presumed to be good, and we still couldn't ascertain that the actual unpack was valid, although it looked to give us a complete root filesystem.  Yesterday @bass_rock and I were both running "repack" tests on a stock bzroot to try and get that working, confident that if we could do that the issue would be solved.  Him on one side of the pond and me on the other..... changing a parameter at a time and discussing it over Discord.  Once again managed to generate a working bzroot file, but tested the same script again and it failed.  Got to admit that confused the hell out of me.....

 

Had to go to the shops to pick up some stuff, which gave me a good hour in the car to think about things and I had a thought, I did a lot of initial repacking on my laptop rather than via an ssh connection to an Unraid VM, and I wondered if that may have been the reason I couldn't reproduce the working repack.  Reason being, tab completion on my Ubuntu based laptop means I have to prepend any script with ./ whereas on Unraid I can just enter the first two letters of the script name and tab complete will work, obviously I will always take the easiest option.  I asked myself if the working build I'd got earlier was failing because it was dependent on being run using ./ and perhaps I'd run it like that on the occasions it had worked.

 

Chatted to bass_rock about it and he kicked off a repackaging of stock bzroot build with --no-absolute-filenames removed from the cpio bit and it worked, we can only assume something must have changed LT side at some point.

 

To put it into context this cpio snippet we've been using since at least 2014/5 or whenever I started with the DVB builds.

 

The scripts to create a Nvidia build are over 800 lines long (not including the scripts we pull in from Slackbuilds) and we had to change 2 of them........

There are 89 core dependencies, which occasionally change with an extra one added or a version update of one of these breaks things.


I got a working Nvidia build last night and was testing it for 24 hours then woke up to find FML Slackbuilds have updated the driver since.  Have run a build again, and it boots in my VM.  Need to test transcoding on bare metal but I can't do that as my daughter is watching a movie, so it'll have to wait until either she goes for a nap or the movie finishes.

 

 Just thought I'd give some background for context, please remember all the plugin and docker container authors on here do this in our free time, people like us, Squid, dlandon, bonienl et al put a huge amount of work in, and we do the best we can.

 

Quote

Where it at yo? 😈

 

Quote

Yes please. I am getting tired of the constant reminders to upgrade to RC7. Cant because my PLEX server will lost HW Transcoding.

 

Comments like this are not helpful, nor appreciated, so please read the above to find out, and get some insight into why you had to endure the "exhaustion" of constant reminders to upgrade to RC7. 

 

On 11/27/2019 at 8:10 PM, leejbarker said:

Hi,

 

Completely understand you guys do this in your spare time and I really am thankful for your work so far.

 

I've got a 1650 super recently and I'm just wondering when we might see a driver update...

 

Thanks

On 11/29/2019 at 9:30 AM, the1poet said:

Hi aptalca. Appreciate the work the team does.

 

Comments like this are welcome and make me happy..... :D

 

 

EDT: Tested and working, uploading soon.

2019-12-01_09-40.png.b65cc29154f794c531bb1287329270cc.png

 

 

Edited by CHBMB
  • Like 3
  • Thanks 10
  • Haha 1
Link to comment
  • trurl locked this topic
Guest
This topic is now closed to further replies.