imthekuni

Members
  • Posts

    19
  • Joined

  • Last visited

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

imthekuni's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. I did a little bit of troubleshooting in the meantime. I noticed that ipmisensors just pulls info from the ipmi.cfg file and passes it to /usr/sbin/ipmisensors via: [ $NETWORK == "enable" ] && OPTIONS=" -h $IPADDR -u $USER -p $(echo $PASSWORD | base64 --decode)" That is when I noticed it is expecting the password to be coded as base64. If I code my PW as base64 it prevents the "base64: invalid input" error I saw earlier. However, I still get the "/usr/sbin/ipmi-sensors: connection timeout" error. If I call /usr/sbin/ipmi-sensors directly I see all the correct info, but for some reason calling it from the script results in a timeout. The only for me to get around this was to comment out the network parsing from ipmi.cfg #!/bin/bash CONFIG="/boot/config/plugins/ipmi/ipmi.cfg" OPTIONS="" IGNORED="" # read our configuration [ -e "$CONFIG" ] && source "$CONFIG" #[ $NETWORK == "enable" ] && OPTIONS=" -h $IPADDR -u $USER -p $(echo $PASSWORD | base64 --decode)" [[ $IGNORE != "" ]] && IGNORED=" -R $IGNORE " /usr/sbin/ipmi-sensors $OPTIONS $IGNORED $@ I have confirmed the IPADDR, USER, and PASSWORD (as base64 or not) are correct in the ipmi.cfg, but something about calling it from the script results in the timeout. Using "whoami" from within the script or the command line shows both are being run as root.
  2. Likewise just throws that base64 error. root@Tower:~# /usr/sbin/ipmisensors base64: invalid input /usr/sbin/ipmi-sensors: connection timeout Much appreciated, I will try and figure out how to convert it to the shell script as well.
  3. I recently noticed that the Controlr plugin is stopped. Disabling and enabling it will set the status to Running for a short while, but then it will switch back to stopped after a few seconds. The controlr.log is: I: 2020/12/20 15:52:51 app.go:58: controlr v2020.05.09|2.19.0 starting ... I: 2020/12/20 15:52:51 app.go:66: No config file specified. Using app defaults ... I: 2020/12/20 15:52:51 app.go:171: host(https://192.168.2.250:443) I: 2020/12/20 15:52:51 core.go:81: starting service Core ... I: 2020/12/20 15:52:51 core.go:307: Created ipmi sensor ... I: 2020/12/20 15:52:51 core.go:334: No ups detected ... I have gone through the topic and tried various suggested troubleshooting steps. If I run /usr/local/emhttp/plugins/controlr/controlr -port 2378 -showups (same results if I include the certs argument), I get: I: 2020/12/20 15:54:30 app.go:58: controlr v2020.05.09|2.19.0 starting ... I: 2020/12/20 15:54:30 app.go:66: No config file specified. Using app defaults ... I: 2020/12/20 15:54:30 app.go:266: cert: found Tower_unraid_bundle.pem I: 2020/12/20 15:54:30 app.go:171: host(https://192.168.2.250:443) I: 2020/12/20 15:54:30 core.go:81: starting service Core ... I: 2020/12/20 15:54:30 core.go:307: Created ipmi sensor ... I: 2020/12/20 15:54:30 core.go:325: Created apc ups ... 2020/12/20 15:54:50 Unable to wait for process to finish: exit status 1 /usr/bin/sensors -A is detecting sensors and providing data. /sbin/apcaccess pulls up my UPS info. However, I think there is an issue with creating the ipmi sensors. I do have a /boot/config/plugins/ipmi/ipmi.cfg. When I run /usr/sbin/ipmisensors --comma-separated-output --output-sensor-state --no-header-output --interpret-oem-data I get base64: invalid input /usr/sbin/ipmi-sensors: connection timeout However, if I run /usr/sbin/ipmi-sensors --comma-separated-output --output-sensor-state --no-header-output --interpret-oem-data It pulls all my info as expected 4,CPU Temp,Temperature,Nominal,53.00,C,'OK' 71,System Temp,Temperature,Nominal,32.00,C,'OK' 138,Peripheral Temp,Temperature,Nominal,0.00,C,'OK' 205,PCH Temp,Temperature,Nominal,48.00,C,'OK' 272,P1-DIMMA1 TEMP,Temperature,Nominal,42.00,C,'OK' 339,P1-DIMMA2 TEMP,Temperature,N/A,N/A,C,N/A 406,P1-DIMMB1 TEMP,Temperature,Nominal,41.00,C,'OK' 473,P1-DIMMB2 TEMP,Temperature,N/A,N/A,C,N/A 540,P1-DIMMC1 TEMP,Temperature,Nominal,45.00,C,'OK' 607,P1-DIMMC2 TEMP,Temperature,N/A,N/A,C,N/A 674,P1-DIMMD1 TEMP,Temperature,Nominal,45.00,C,'OK' 741,P1-DIMMD2 TEMP,Temperature,N/A,N/A,C,N/A 808,FAN 1,Fan,Nominal,375.00,RPM,'OK' 875,FAN 2,Fan,N/A,N/A,RPM,N/A 942,FAN 3,Fan,N/A,N/A,RPM,N/A 1009,FAN 4,Fan,N/A,N/A,RPM,N/A 1076,FAN A,Fan,N/A,N/A,RPM,N/A 1143,Vcore,Voltage,Nominal,1.00,V,'OK' 1210,3.3VCC,Voltage,Nominal,3.30,V,'OK' 1277,12V,Voltage,Nominal,11.98,V,'OK' 1344,VDIMM,Voltage,Nominal,1.35,V,'OK' 1411,5VCC,Voltage,Nominal,5.12,V,'OK' 1478,CPU VTT,Voltage,Nominal,1.06,V,'OK' 1545,VBAT,Voltage,Nominal,3.46,V,'OK' 1612,VSB,Voltage,Nominal,3.55,V,'OK' 1679,AVCC,Voltage,Nominal,3.31,V,'OK' 1746,Chassis Intru,Physical Security,Nominal,N/A,N/A,'OK' Any insight is appreciated!
  4. What exactly is the problem? The fan speed is not "locking" in to what you entered? Fans are always spinning high? They are ramping up and down? Depending on the system fan model, the optimal setting of 30% PWM could be around 4k rpm (~13k max rpm. I think the original server fans spin pretty fast/loud. Might have to upgrade to slower/quieter ones like the Noctua NF-A8 PWM (2200 max rpm) May run into the ramping issue when switching. I found this guide (https://pgfitzgerald.wordpress.com/2017/02/18/new-home-lab/) to be the easiest to follow and may help with the ramping issue. I installed the IPMI tools on my computer (Mac) and used the following commands: ipmitool -I lanplus -H IPMI_IP_ADDRESS -U USER_NAME -P USER_PASSWORD sensor list all where IPMI_IP_ADDRESS is the IP for your IPMI port, USER_NAME is your user name ("Admin"?), and USER_PASSWORD is your password. That should pull up all of your available sensors like fan speeds, temps, voltages, etc. The headers correspond to: Name Reading Unit Status Lower Non-Recoverable Lower Critical Lower Non-Critical Upper Non-Critical Upper Critical Upper Non-Recoverable You will want to set the upper and lower fan speed thresholds. The value can be determined by "calculating the lowest and highest angular velocities your fan is rated to run at (check the manufacturer's specs). For instance, [the] Noctua NF-F12 IndustrialPPC 3000 PWM are rated at 750RPM +-20% at the low end, so 600RPM or less is an appropriate lower non-critical threshold value. To get the other values, subtract 100 for the lower critical and 200 for the lower non-recoverable." Then you can change the desired fan speed thresholds via ipmitool. For example, to change the lower fan speeds for "FAN 1", use: ipmitool -I lanplus -H IPMI_IP_ADDRESS -U USER_NAME -P USER_PASSWORD sensor thresh "FAN 1" lower *lnr* *lc* *lnc* Where *lnr* = the Lower Non-Recoverable speed, *lc* = Lower Critical, and *lnc* = Lower Non-Critical speeds. Similarly, the upper speeds can be calculated and entered using: ipmitool -I lanplus -H IPMI_IP_ADDRESS -U USER_NAME -P USER_PASSWORD sensor thresh "FAN 1" upper *unr* *uc* *unc* Where *unr* = the Upper Non-Recoverable speed, *lc* = Upper Critical, and *lnc* = Upper Non-Critical speeds. Note that the system may round the values to a nearby valid number (e.g., 510 to 500). To check that the values are sticking, check the values using the first linked code above. Hopefully this helps!
  5. Might be a long shot, but if you have an extra SSD, or can get one cheap, you could boot Windows off that to debug the board
  6. Someone can correct me if I'm wrong, but I think docker containers must run some *nix OS. Unfortunately it does not look like MSI makes a compatible application (Windows only) which limits you to a VM, however I am not sure if it possible to access SuperI/O from a VM...
  7. Darn. I was hoping since your MB has the same SuperI/O chip that it would just work. I tried looking at the source code, but it is a little over my head at that point.
  8. Oh yes, should have mentioned this. It should default to docker-msi-rgb. I did have another docker container called msi-rgb that I have since deleted, so be sure to install docker-msi-rgb
  9. Oh, you'll have to get into your docker container first. So once you're logged into the server (telnet, ssh, or webgui terminal): docker exec -it docker-msi-rgb bash
  10. Its a little janky (I am not the best at making docker containers) but hopefully it works! You should only need to set the docker to privileged. No need to open ports, variables, etc. Not as user friendly as an app with a GUI, but hopefully useful enough that you don't have to constantly run a VM. Also, there is probably a way to have the code run on restart so that the lights are set if you ever reboot your unraid server
  11. So I was curious and I made Docker container that has a linux utility to adjust RGB on MSI motherboards. Possible it will work on yours. Give it a shot, just search for my name (imthekuni) on the community app store, it won't show up so search Docker Hub from the link, and install docker-msi-rgb. Install as a privileged docker. You can then telnet or ssh into your server, or if you are on 6.4, you can use the terminal from the web GUI. To change color settings: For Green /msi-rgb/target/release/msi-rgb 00000000 FFFFFFFF 00000000 For Heartbeat /msi-rgb/target/release/msi-rgb 206487a9 206487a9 10325476 -ir -ig -ib -d 5 For Police /msi-rgb/target/release/msi-rgb -d15 FF00FF00 0 00FF00FF Documentation can be found here. Notice that the path is different (starts as /msi-rgb/target/... instead of ./target/...) and that you do not need to sudo.
  12. A cursory Google search is not providing much. Not sure you can access the chip required to control RGB through a VM, but you might be able to get away using this tool and creating a docker container for it?
  13. This may be a stretch, but could you somehow pass RGB through to VM? Does it show up as a separate IOMMU group? (Tools > System Devices)
  14. RT-AC56U with stock firmware. At this point in my life I just need something that works!
  15. I just picked up 2 of these for my Dell H310 and they work like a charm.