ich777

Yeah, these new GPUs can produce pretty significant Power Spikes in your system and this could be one reason why the GPU falls from the bus and doesn't recover properly.

I don't think that there is any. The default name should be VEIN, please look up how to configure your Dedicated VEIN Server, there should be plenty tutorials be out there, the default config should be in: .../Vein/Saved/Config/LinuxServer/Engine.ini

Sorry about that but currently my time is very limited and I barely have time to maintain everything, but as always I try my best. :) If you find a solution please post it here so that others can also benefit from it.

Then hosting a STUN/TURN Server is most of the times impossible. But we are not talking about a Webserver, STUN/TURN, is it's own application and won't make use of that. Again, a STUN/TURN Server should be deployed on a VPS outside your network, TBH most of the times it's enough to use any of the public available STUN/TURN servers since they only provide the IP where to connect. You can take a look here. A STUN/TURN Server is not a simple Webserver.

VM as @itimpi said and sometimes on my main machine too, I don't have a tutorial for that.

Please do keep in mind that a STUN-TURN Server needs to have direct access to the internet without any NAT and usually you don't have it on your network because otherwise it will give you the wrong IP addresses. Jup, STUN-TURN needs to be directly reachable from the Internet. It has to run in host or in br0/eth0 mode otherwise it won't work properly.

Never bothered me but I haven't looked into that yet if that's even possible to change. IIRC someone already asked because he found no solution to that.

Did you change anything in the template? Especially the path to the gamefiles? If yes, make sure that the path reflects the path to the gamefiles on disk and not to /mnt/user/appdata/... so to speak something like /mnt/cache/appdata/... or /mnt/disk1/appdata/... The container won't run properly on /mnt/user/...

The command needs to be executed exactly once, when the server starts. I would leave it in the go file. Oh and please execute it once if you haven't rebooted yet. Few users said that this solved their issues.

This is a common issue with newer cards it seems. Please try to add: nvidia-persistenced to your go file and reboot. However most of the times it seems some kind of hardware compatibility issue. Make sure your BIOS is up to date, you have Resizable BAR Support and above 4G Decoding enabled in your BIOS. Check that you PSU is up to the task (please don't forget that PSUs degrade over time). This is a different issue and not related to the other issue. Can you also please send a screenshot from your plugin page please.

Report it to Steam. I really don't know how I can mitigate the issue since if I would delete this file everytime the container is restarting this would mean significant longer start times because a check from all files will happen and I'm not a big fan from that since for users it is working this would be a major annoyance. However you can create a script on the host (Unraid) that you mount into the container to /opt/scripts/user.sh which deletes the files inside the container /serverfiles/steamapps/appmanifest_2430930.acf will also do the job, but I won't recommend that since this would mean every time the container starts a check is performed.

Really strange... However if it's working then I'm fine with it. :)

This is a SteamCMD issue, I can't fix that since if I would delete that file, every time the container starts a complete check from the already installed files is triggered and for some users it's actually working.

Yeah, the lines from my previous post, change the user, then creates the folder and creates the file if executed correctly. However what is the exact issue? I'm not familiar with any issues in German.

User Scripts has a Schedule build in, which is deactivated by default, to prune all unused images. Maybe enable that on the Backup server to remove those images on a daily basis. That would be the easiest way.

Sorry, I really can't help here since I don't know Distrobox. But a installation should be possible I assume through a plugin.

Cool, didn't know that you can't change the driver version. :D For now yes because I haven't changed legacy versions, who knows what Nvidia does next and if they stick to that that driver 580 is now legacy but I will fix that eventually.

That should work just fine IIRC.

What do you mean with reloaded? If the path exists and the container is able to write to this path the key won't be refreshed, if it's refreshed there is something not correctly configured in terms of the path I assume. I really can't tell since it's working on my server and I assume for many others here too. The key is physically written into the main directory from the container and displayed on every start from the container in the logs, if the keyfile exists it won't be overwritten.

Please see this post (different container but probably the same issue) :

It seems now that Nvidia made 10 series now legacy which basically means that you are stuck on driver version 580, however please keep in mind that Pascal so to speak 10 series cards are now almost 10 years old. It's also clearly visible in the syslog: Dec 5 07:26:34 Tower kernel: NVRM: The NVIDIA NVIDIA GeForce GTX 1060 6GB GPU installed in this system is Dec 5 07:26:34 Tower kernel: NVRM: supported through the NVIDIA 580.xx Legacy drivers. Please Dec 5 07:26:34 Tower kernel: NVRM: visit http://www.nvidia.com/object/unix.html for more Dec 5 07:26:34 Tower kernel: NVRM: information. The 590.44.01 NVIDIA driver will ignore Dec 5 07:26:34 Tower kernel: NVRM: this GPU. Continuing probe... Dec 5 07:26:34 Tower kernel: NVRM: The NVIDIA NVIDIA GeForce GTX 1050 Ti GPU installed in this system is Dec 5 07:26:34 Tower kernel: NVRM: supported through the NVIDIA 580.xx Legacy drivers. Please Dec 5 07:26:34 Tower kernel: NVRM: visit http://www.nvidia.com/object/unix.html for more Dec 5 07:26:34 Tower kernel: NVRM: information. The 590.44.01 NVIDIA driver will ignore Dec 5 07:26:34 Tower kernel: NVRM: this GPU. Continuing probe... Dec 5 07:26:34 Tower kernel: NVRM: No NVIDIA GPU found.

Please read the post above yours and you have your answer (especially the last paragraph).

First of all, does anyone of you two have Diagnostics from where the issue occurred? Otherwise it is really hard to troubleshoot. You are talking about Driver version 590.44.01 correct (please also do keep in mind that this is a beta driver - latest is not always grates :D )? Issue here is more the hardware that you are using, this is the first driver which is dropping everything before the first RTX series (Turing), so to speak Pascal and everything before is not supported anymore, please see (under the section Supported Products) : https://www.nvidia.com/en-us/drivers/details/258750/ You now have to make sure that you stay below driver version 590

Are you sure that Above 4G Decoding is enabled and Resizable BAR Support is enabled? You have a lot of these messages in your sysslog: Dec 3 08:48:41 Tower kernel: NVRM: This PCI I/O region assigned to your NVIDIA device is invalid: Dec 3 08:48:41 Tower kernel: NVRM: BAR1 is 0M @ 0x0 (PCI:0000:0c:00.0) Dec 3 08:48:41 Tower kernel: NVRM: This PCI I/O region assigned to your NVIDIA device is invalid: Dec 3 08:48:41 Tower kernel: NVRM: BAR2 is 0M @ 0x0 (PCI:0000:0c:00.0) and as a result from this message: Dec 3 08:50:36 Tower kernel: NVRM: kbusVerifyBar2_GB202: MMUTest BAR0 window offset 0x70e000 returned garbage 0x0 Dec 3 08:50:36 Tower kernel: NVRM: nvAssertOkFailedNoLog: Assertion failed: Generic memory error [NV_ERR_MEMORY_ERROR] (0x00000072) returned from kbusVerifyBar2_HAL(pGpu, pKernelBus, NULL, NULL, 0, 0) @ kern_bus_gm107.c:352 Dec 3 08:50:36 Tower kernel: NVRM: nvAssertOkFailedNoLog: Assertion failed: Generic memory error [NV_ERR_MEMORY_ERROR] (0x00000072) returned from kbusStateInitLockedKernel_HAL(pGpu, pKernelBus) @ kern_bus_gm107.c:457 Dec 3 08:50:36 Tower kernel: NVRM: RmInitNvDevice: *** Cannot initialize the device Dec 3 08:50:36 Tower kernel: NVRM: RmInitAdapter: RmInitNvDevice failed, bailing out of RmInitAdapter Dec 3 08:50:36 Tower kernel: NVRM: rmapiReportLeakedDevices: Device object leak: (0xc1e00003, 0xcaf00000). Please file a bug against RM-core. Dec 3 08:50:36 Tower kernel: NVRM: nvAssertFailedNoLog: Assertion failed: 0 @ rmapi.c:935 Dec 3 08:50:36 Tower kernel: NVRM: rmapiReportLeakedDevices: Device object leak: (0xc1e00004, 0xcaf00000). Please file a bug against RM-core. Dec 3 08:50:36 Tower kernel: NVRM: nvAssertFailedNoLog: Assertion failed: 0 @ rmapi.c:935 Dec 3 08:50:36 Tower kernel: NVRM: nvAssertFailedNoLog: Assertion failed: listCount(&pKernelBus->virtualBar2[gfid].usedMapList) == 0 @ kern_bus_vbar2.c:346 Dec 3 08:50:36 Tower kernel: NVOC: __nvoc_objDelete: Child class KernelVideoEngine not freed from parent class OBJGPU.NVRM: iovaspaceDestruct_IMPL: 4 left-over mappings in IOVAS 0xc00 Dec 3 08:50:36 Tower kernel: NVRM: GPU 0000:0c:00.0: RmInitAdapter failed! (0x24:0x72:1100) Dec 3 08:50:36 Tower kernel: NVRM: GPU 0000:0c:00.0: rm_init_adapter failed, device minor number 0 Dec 3 08:50:36 Tower kernel: NVRM: _kgspBootGspRm: unexpected WPR2 already up, cannot proceed with booting GSP Dec 3 08:50:36 Tower kernel: NVRM: _kgspBootGspRm: (the GPU is likely in a bad state and may need to be reset) Dec 3 08:50:36 Tower kernel: NVRM: RmInitAdapter: Cannot initialize GSP firmware RM Dec 3 08:50:36 Tower kernel: NVRM: GPU 0000:0c:00.0: RmInitAdapter failed! (0x62:0x40:1860) Dec 3 08:50:36 Tower kernel: NVRM: GPU 0000:0c:00.0: rm_init_adapter failed, device minor number 0

Are you sure that it doesn't boot or do you see just a blinking cursor in the top left corner? Just to be clear, the OpenSource driver only supports GPUs RTX20 and up (including the GTX16 series) and the other drivers only supports up to RTX40 series. So to speak you can't utilize both cards in your system, it's either you P2000 or your RTX5060ti. I'm not sure what's going on with the boot issue since this seems very strange to me and usually has nothing to do with the Nvidia Driver. From what I see from you Diagnostics, the RTX5060ti is properly recognized and should work, I see no other obvious issue. If the card is dropping from the Bus then you can try to put nvidia-persistenced in your go file. Please also check that your Power Supply is up to the task since they degrade over time.