ich777

I don't think that this option makes you server went crazy. This is more likely the case, but as said above I can't imagine that only the power on after failure option will mess things up. Yes and no, for example, it would be good if you have internet when the server boots back up since it checks for new packages on every boot but even if you don't have internet it will work just fine, the boot process will just take a bit longer. Are you sure that the VMs are shutting down correctly when they receive the stop command from libvirt? However, what timeouts have you set in your settings for the VMs (and maybe also for Docker)? What happens when you let everything run and then issue `powerdown` from an Unraid Terminal, does the Server shutdown correctly? I'm asking again because you haven't yet answered, have you yet looked into /boot/logs if there are any Diagnostics? The server will create Diagnostics when it fails to shutdown.

To fix the bug it would be best to make limetech aware of that but may I ask why you are on such an old version anyways? I disagree heavily on that, back in the days where my Unraid-Kernel-Helper was around which modified the bz* files to bundle specific drivers it was really hard some times to troubleshoot because users had customized bz* files, which at the time was not obvious and not part of the Diagnostics. Keep in mind if someone modifies their bz* files and maybe change something by accident this could cause other issues too... Wouldn't that be solved by --reinstall or even using installpkg instead of upgradepkg, there would be other ways around this to BTW... Another overlay fs or you even could use the driver plugin installation logic for that... However I would strongly discourage users to modify their bz* files.

Why would you do that? What do you need or is missing? I encourage users nowadays not to do this.

So it started to be unreliable after a power outage correct? This won't change much. Shut down the server and wait for you power outage, after that start the server again, let it run for a day and then post your Diagnostics again. Have you yet looked on your USB Boot device if in the folder /boot/logs are any Diagnostics? If so please post them.

What kind of machine is this Initiator? It seems that it sends requests that the Target can't handle and that's why you see those messages. Maybe these are proprietary requests that this BOSCH machine is using, maybe try to look on the Initiator side and see if you can deactivate them.

Yes I can. Correct my if I'm wrong but you are using this NUC compute module with a PCIe interface on the bottom and connect a GPU to it correct? What is you exact issue? If it's related to the Nvidia Driver plugin I would strongly recommend that you create a post in the Nvidia Driver thread with fresh Diagnostics, also check your /logs folder on your boot device since it will create every time a shutdown failes a Diagnostics file. Please make also sure that you have Above 4G Decoding and Resizable BAR enabled in your BIOS. Make also sure that you are on the latest BIOS version.

Are you really sure that this card is supported in your server? HP servers often have a device lock and they only allow certain cards to work. However the lockups that you are experiencing is most certainly because of the plugin calling nvidia-smi and that's what causing that. Are you sure that the card is working properly? Please check if you have Above 4G decoding and Resizable Bar support enabled in your BIOS. Are you also sure that your power supply is able to deliver enough power to the card? Can you swap the card to another PCIe slot? Are you on the latest BIOS version from your Motherboard?

Thank you, really much apprechiated. Merry Christmas!

My general recomendation is that you set your appdata share to stay on the cache and not to be moved from the cache to the array since otherwise the array never can go into spindown. The appdata directory usually contains data that your server has to access quickly and all the time that‘s why I recommend not moving it to the array.

Usually these are WINE messages and should not hatm anything. Is the container not working? What happens when you restart the container? Do you maybe have the full log?

What Initiator are you using exactly and how is it configured? This should not harm anything since it says:

The plugin currently says r8186 and it should be r8168, it doesn't matter if you search for r8168 or rtl8168, already issued a PR. Sorry @Squid

The IT87 plugin does nothing on it's own, it only installs and loads the driver.

Oh sorry, I've pushed that against master that should be 6.13.0 and not 6.12.x

Please search for rtl8168 there is a typo in there.

NTFY should be an agent by default and you don't have to do anything as the post above yours imply.

Have you yet tried to uninstall the IT87 plugin to? Maybe it is not related to any plugin and is a hardware thing?

Did you make sure that you've exit the application once from inside the container and let it restart on it's own? This is the first time that I hear of that issue.

FYI: The driver itself (CAN_GS_USB and all dependencies) will be included in 6.12.7+

FYI: The driver itself will be included in 6.12.7+

On it's own the container won't wipe the data in there. Are you sure it had to do an updated? Can you please share a bit more details, screenshot from your template? Are you also sure that the share where the game files are located is staying on the Cache and is not moved to the Array? If not this is most likely the cause of the issue and your world/backups are on the Array but it simply can't find it because the path in the container template points to the Cache and the actual game files and everything else are now on the Array <- this could also be the case why it pulled an update, as far as I'm aware there where no recent Valheim updates.

There is nothing to be sad about, you have nothing to do if you have installed my template, it will work as usual but I do no support requests anymore for that container. I use Nextcloud, for my needs more than enough. This is the official image from PhotoPrism and since it's out of my control and I don't use it I simply don't want to maintain the Unraid template anymore.

I mean both, this can ultimately boil down to a hardware compatibility issue.

As said, this could be also a Firmware issue, so to speak a BIOS error which most of the times isn't solved with a BIOS update.

Are you sure that the sensors stop working? Did you ever issue sensors after the fans stopped spinning? If the sensors are working properly this is more a Autofan issue than from the plugin/driver. However this is the first time that I hear from this issue and this could also indicated already a hardware failure.