mergleh

For anyone that may run into this, I was able to resolve this by using the SUM tool to update the DMI information. Download SUM here https://www.supermicro.com/en/solutions/management-software/supermicro-update-manager Execute 1) ./sum -i <IPMI_IP> -u <admin_username> -p <admin_password> -c GetDmiInfo --file dmi.txt a) This downloads the DMI info to a text file. 2) Open dmi.txt and update the information here - in my case, there were 3 examples of the problematic manufacturer name... I'm not sure which of the 3 was the right one so I just updated them all. 3) ./sum -i <IPMI_IP> -u <admin_username> -p <admin_password> -c ChangeDmiInfo --file dmi.txt --reboot b) This will write the changes you made to the txt file to DMI and trigger a reboot of the BMC. Obviously, you should make sure Unraid isn't running in the background. I don't think updating FRU info is necessary as I did that first with no luck (makes sense given that the plugin is using dmidecode).

Hello, I recently purchased a Supermicro X11SCA-F from eBay and noticed that I've lost the fan config tab in IPMI Tools. Doing some digging through this thread, it seems that this may be because the plugin is not detecting a supported manufacturer when it initializes. Running one of the commands I found on this thread, I'm seeing the following: dmidecode -t 2 | grep 'Manufacturer' | awk -F 'r:' '{print $2}' | awk '{print $1}' Enginetech I'm not sure why this is returning Enginetech (EG320W-G20) instead of Supermicro (X11SCA-F)... I think the likely reason is that this board was refurbished in some way and it was changed as a part of that process. I'm wondering if there's any way to work around this to be able to configure the fans using the IPMI plugin. Thanks!

Hi all, I'm hoping I can get some guidance on a problem I'm having. I have CA Backup/Restore scheduled to run at 3am every day. When it runs, 7 of my 8 containers start up afterward, but one does not start. The log for that container just indicates that it was shut down at 3am, but I see no indication that it tried to start again. I've tried adding a few 'extra parameters' like '--restart unless-stopped' and '--restart -always' but the behavior does not change (likely by design given my limited understanding of how those parameters work). I've also tried installing the User Scripts plugin and creating a daily script that will just run 'docker start SABnzbd' but it's failing due to an issue mounting an SMB location that I have connected to the container. Ideally I'd prefer to do this without a script since I don't think it should be needed, however, I'm not sure what I can look at to determine why that one container isn't starting after the backup completes. I'm wondering if there is a log file for this plugin so I can see if there was some kind of problem starting the container after the backup completed. Any guidance you all can offer would be appreciated. I've attached the bit of logging from when the container is shut down, but I don't think it's going to be very helpful. sab-docker.txt