ljm42

What version of unRAID do you have? can you post a screenshot?

In the unRAID webgui, go to the Docker tab. Edit the docker. Find the volume mapping(s) that are pointed to an unassigned device. Hit Edit. Change the access mode to RO/Slave or RW/Slave. Only make this change for paths pointing to an unassigned device.

From Squid's link: you need to adjust your volume mappings mode (usually either RW or Read Only) to be RW:Slave or Read Only:Slave)

This works great on both my bare metal system and my VM! One thing to note - if you change the ipmi sensors you have to stop/restart the controlr plugin for it to pick up the change. Normally this is a set it and forget it type of thing anyway, so it isn't really a problem, just something to be aware of.

Cool, so v2018.01.30b solves the connection problem for @wgstarks, now it is just a matter of reading the DISP_SENSOR1-4 values to display the right things. I'm still having trouble with my VM though. Maybe this will help... There are four "states" that IPMI operates in: local IPMI available, accessed locally (ljm42's bare metal system) local IPMI available, accessed via network (wgstarks) local IPMI not available, accessed via network (ljm42's VM) local IPMI not available, not accessed via network (everyone without IPMI) So the rough logic would be: if ( (local IPMI available) or (network IPMI access enabled) ) { run /usr/sbin/ipmisensors } where "local IPMI available" is based on the existence of various files as discussed here: https://lime-technology.com/forums/topic/38108-plugin-ipmi-for-unraid-61/?page=35&tab=comments#comment-618493 and "network IPMI access enabled" is based on whether /boot/config/plugins/ipmi/ipmi.cfg contains NETWORK="enable"

Thanks for this, it is really cool It works on my bare metal system, but not my VM. Based on the debug log, it looks like you are calling: /usr/sbin/ipmi-sensors --comma-separated-output --output-sensor-state --no-header-output --interpret-oem-data The plugin creates a shell script that knows how to connect to the ipmi host via the network, would you please call this instead? /usr/sbin/ipmisensors --comma-separated-output --output-sensor-state --no-header-output --interpret-oem-data That would allow controlr running in a VM to read the IPMI data from the IPMI host. The output from either is the same on bare metal: 3,ATX+5VSB,Voltage,Nominal,4.92,V,'OK' 4,+3VSB,Voltage,Nominal,3.44,V,'OK' 5,Vcore,Voltage,Nominal,1.80,V,'OK' 6,VCCM,Voltage,Nominal,1.51,V,'OK' 7,+1.05,Voltage,Nominal,1.07,V,'OK' 8,VCCIO_OUT,Voltage,Nominal,1.01,V,'OK' 9,BAT,Voltage,Nominal,3.28,V,'OK' 10,+3.30V,Voltage,Nominal,3.38,V,'OK' 11,+5.00V,Voltage,Nominal,5.07,V,'OK' 12,+12.00V,Voltage,Nominal,12.10,V,'OK' 13,CPU_FAN1,Fan,Nominal,1100.00,RPM,'OK' 14,REAR_FAN1,Fan,Nominal,500.00,RPM,'OK' 15,FRNT_FAN1,Fan,Nominal,500.00,RPM,'OK' 16,M/B Temperature,Temperature,Nominal,36.00,C,'OK' 18,CPU Temperature,Temperature,Nominal,37.00,C,'OK' In case it helps, here is my bare metal ipmi.cfg: IPMISELD="disable" IPMIPOLL="60" NETWORK="disable" LOCAL="disable" IPADDR="" USER="" PASSWORD="" DISP_SENSOR1="18" DISP_SENSOR2="16" DISP_SENSOR3="15" DISP_SENSOR4="13" LOADCFG="disable" DASHTYPES="Temperature,Fan" IGNORE="" DIGNORE="3,4,5,6,7,8,9" DASH="enable" DEVIGNORE="SanDisk_Cruzer_Fit_4C530001901204112304-0:0" DEVS="enable" and here is the VM's ipmi.cfg: SERVICE="disable" IPMIPOLL="300" NETWORK="enable" LOCAL="disable" IPADDR="192.168.10.50" USER="admin" PASSWORD="<snip>" IPMISELD="disable" IPMIFAN="disable" IPMIBOARD="" DISP_SENSOR1="3232238130_18" DISP_SENSOR2="3232238130_16" DISP_SENSOR3="3232238130_15" DISP_SENSOR4="3232238130_13" IGNORE="" DASHTYPES="Temperature,Fan" DIGNORE="3,4,5,6,7,8,9" DASH="enable" DEVIGNORE="" DEVS="enable" Also, I'm curious about the data. In the plugin settings I have chosen four sensors: DISP_SENSOR1="18" <--- CPU temp DISP_SENSOR2="16" <--- MB temp DISP_SENSOR3="15" <--- front fan DISP_SENSOR4="13" <--- rear fan Is the app using those settings or figuring out on its own what to display? I ask because the app is showing three fans and the CPU temp, instead of two fans and two temps: I: 2018/01/30 09:52:30 utils.go:175: debug:executing:(/usr/sbin/ipmi-sensors):([--comma-separated-output --output-sensor-state --no-header-output --interpret-oem-data]) I: 2018/01/30 09:52:31 utils.go:175: debug:executing:(/sbin/apcaccess):([]) I: 2018/01/30 09:52:31 api.go:142: info({Version:2 Wake:{Mac:<snip> Broadcast:255.255.255.255} Prefs:{Number:., Unit:C} Samples:[{Key:FAN Value:1100 Unit:rpm Condition:neutral} {Key:FAN Value:500 Unit:rpm Condition:neutral} {Key:FAN Value:500 Unit:rpm Condition:neutral} {Key:CPU Value:37 Unit:C Condition:neutral} {Key:UPS STATUS Value:Online Unit: Condition:green} {Key:UPS LOAD Value:17.0 Unit:% Condition:green} {Key:UPS CHARGE Value:100.0 Unit:% Condition:green} {Key:UPS LEFT Value:54.5 Unit:m Condition:green} {Key:UPS POWER Value:86.7 Unit:w Condition:green}] Features:map[sleep:false]})

The controlr plugin starts now and the app sees logs and ups data. Nice! I'm not seeing any IPMI data yet, but I don't think that is fully enabled yet, right? Hopefully it will use all the same IPMI settings that the plugin does? One small corner case for the app... when there is no parity drive installed there shouldn't be a 'check parity' option.

A couple of people have been caught off guard by it: https://lime-technology.com/forums/topic/67222-64-cache-issue-due-to-uad-plugin/ https://lime-technology.com/forums/topic/68683-cache-drive-wont-load/ I have no idea how prevalent it is though. Thinking about it more... when people pick a port that is already in use, they'll discover there is a problem before FCP can help anyway. And convincing people to change a working system "just in case" is an uphill battle. Probably makes more sense for the webgui to take a stand before FCP does: https://lime-technology.com/forums/topic/61773-64-needs-to-help-users-avoid-port-conflicts/ True, Ryzen is definitely a moving target I couldn't test that myself either, but I did try adding "diagnostics" to my go script and it failed. Then I had it echo the $PATH variable and discovered /usr/local/sbin isn't part of the $PATH available to the go script. So I do believe the full path is needed for it to have any effect. But it might make sense to wait and see what 6.4.1 does with zenstates/Ryzen. Anyway, hopefully this wasn't a complete waste of your time I do realize that you're basically stuck supporting / defending anything you add to FCP, so I completely understand that you can't do something you don't believe in.

Hi @Squid, Here is a laundry list of ideas for FCP to check. It is possible they are too opinionated or too obscure or too hard to support, but I thought I'd mention them. And apologies if FCP already does any of them 1. Check if a cache drive need to be reformatted because it was created in an older version of UD: forums/topic/67222-64-cache-issue-due-to-uad-plugin/?tab=comments#comment-623856 2. Check docker xml files for environment variables being passed as extra params ("- e") . This is being recommended in the Lets Encrypt thread and it causes problems when the extra params conflict with variables set in the docker templates: https://lime-technology.com/forums/topic/51808-support-linuxserverio-letsencrypt-nginx/?page=49&tab=comments#comment-619701 3. Check for "--device" being passed to dockers as extra params. This is being recommended in these threads: https://forums.lime-technology.com/topic/61583-hw-transcoding/?do=findComment&comment=605041 https://forums.lime-technology.com/topic/40463-support-linuxserverio-plex-media-server/?do=findComment&comment=544102 and could result in the same issue as above. Better to use fields rather than extra params when the fields are available. 4. If unRAID < 4.6.0 and VMs are enabled, see if domain.cfg is missing a MEDIADIR as this causes problems with the upgrade to 4.6.0 https://lime-technology.com/forums/topic/65755-64-array-starting-starting-services-stuck/?tab=comments#comment-623157 Then again, if 4.6.1 relaxes this requirement it may no longer be an issue. 5. if there are any packages in /boot/extras, recommend that users delete them and install via Nerd Tools plugin instead. 6. Check go script for references to cache_dirs script and suggest installing the Dynamix Cache Directories plugin instead. 7. If the go script (< 6.4.0) or ident.cfg (>= 6.4.0) references ports other than 80 or 443, and if those customized ports are less than 1000, warn the user. The risk is that misusing a "well known" port will cause problems if other services are added to unRAID down the road. 8. If the go script includes "zenstates" without the full path "/usr/local/sbin/zenstates", warn user that it is not actually running. ( When the go script executes, the $PATH variable does not contain "/usr/local/sbin" ) 9. Also... currently I have multiple exclusions related to disks being spun down: * "Disk(s) disk1 disk2 disk3 are spun down. Skipping write check and HPA check": "true", * "Disk(s) disk2 disk3 are spun down. Skipping write check and HPA check": "true", * "Disk(s) disk3 are spun down. Skipping write check and HPA check": "true", Would it be possible to consolidate those down to one exclusion? As I add more drives there will be more combinations. Actually, I'm a little surprised there isn't one for "disk1 disk3" yet.

https encryption? There is no noticeable performance hit. The 6.4 webgui is so much faster you wouldn't notice it even if there was disk encryption? I haven't seen anybody talk about the performance aspects of this. You'll probably have better luck asking in the main release note thread

*Very nice!* This is an excellent overview of the new features in 6.4 and the things to watch our for during the upgrade. It pairs very nicely with this thread: The only extra thing I'd call out is if you have a standard off-the-shelf router and you get the "rebinding error" while trying to provision your SSL Certificate, give it 10 minutes and try again. Sometimes it just takes a little time for the DNS changes to go through.

glad to hear it! honestly, you did the hard part of identifying the error

This was an excellent summary, but I would have preferred to see it in the release thread (thanks to the mod that moved it!) Anyway, I would delete config/ssl/* from the flash drive and reboot. Unraid should regenerate the missing *.pem files. If you still have issues, attach the full diagnostics after your next boot.

excellent!

Following a hint from @bakes82, I think I see the problem. Your /boot/config/domain.cfg file looks like this: SERVICE="enable" IMAGE_FILE="/mnt/user/system/libvirt/libvirt.img" IMAGE_SIZE="1" DEBUG="no" DOMAINDIR="/mnt/user/domains/" MEDIADIR="" VIRTIOISO="" BRNAME="virbr0" VMSTORAGEMODE="auto" Note that the MEDIADIR setting is empty. I just verified on my system that that is required for the array to start. Here is the default: MEDIADIR="/mnt/user/isos/" I'm not sure if VIRTIOISO is required, but here is what I have: VIRTIOISO="/mnt/user/isos/virtio-win-0.1.118-2.iso" Fingers crossed this does it!

Wait 10 minutes and try again. In my experience, the DNS change did not propagate immediately. Not sure if that is because I use OpenDNS or something else.

I'd boot in safe mode, see if the array comes fully up without any plugins. If it does, you can boot normally and start uninstalling plugins until you find the problem. There is a lot of chatter about preclear in the release thread, that's the first one I'd uninstall.

Thanks, it works great! For #3, I was thinking along the lines of maybe adding a plain link right below the list of tabs?

1) I just enabled notifications (with no thresholds) and ran a manual test. For some reason the notification says "FAIL"? Notice [TOWER] - Speedtest Ping [FAIL] <server name> [7.89 km] 41 ms DL: 223.9 Mbps UL: 11.7 Mbps While I'm at it here are a couple of other ideas... 2) Currently the "share" images are loaded via http: http://www.speedtest.net/result/6966318233.png When you are accessing the unRAID webgui via https, this results in a "mixed-content" warning. Would you be open to tweaking the url before loading the image, either making it protocol-relative: //www.speedtest.net/result/6966318233.png or just forcing to https? https://www.speedtest.net/result/6966318233.png 3) Also, since the Speedtest and History tabs are missing from the Scheduler page: /Settings/Scheduler would it be possible to add a link from there back to the tool page? /Tools/SpeedtestTools Without that it is a little difficult to navigate. thanks!

Oh ok, that is probably fine then. Thanks again for all of your work on this.

OK, I understand now. I can modify /etc/rc.d/rc.local_shutdown after upgrading the plugin on that last system. But it makes me a little nervous knowing there is a script called during shutdown that can potentially block the shutdown. I can reproduce the problem by executing /usr/sbin/ipmifan without any parameters, it goes into a loop throwing this error multiple times and never exiting: Warning: Invalid argument supplied for foreach() in /usr/local/emhttp/plugins/ipmi/scripts/ipmifan on line 322 Ideally, all of the scripts would check to confirm the appropriate ipmi variables have been set before they try doing anything. This would ensure they don't have any unintended side effects down the road. Is that reasonable? It isn't super urgent, since there is a workaround for the immediate problem.

I still have one more server to update. Any chance this can be fixed, or should I just delete the ipmifan script before the first reboot?

I had the same issue on my main system and my VM, both on 6.4.0_rc14. They both hung when trying to shutdown after installing the 2017.11.29 version of the IPMI plugin (admittedly, there were likely other changes as well) The VM was nice enough to drop some hints on the console, it complained about an undefined value in line 322 of ipmifan: https://github.com/dmacias72/IPMI-unRAID/blob/master/source/ipmi/usr/local/emhttp/plugins/ipmi/scripts/ipmifan#L322 It was stuck in a loop, displaying that error over and over. My main system did not leave any helpful hints on the console, it just hung. Neither system uses the ipmi fan control, they just display temps and fan speeds. After the first reboot, both systems lost their IPMI plugin settings and had to be reconfigured. Subsequent reboots worked without a problem. Note... the reason for the shutdown was to install the latest BMC/Bios (yay, the ASRock Java IPMI console no longer throws Java security errors!), so it is possible that is the reason I had to reconfigure the plugin.

It is not really safe to randomly pick ports under 1023, as they are often already in use. Here is a list of known ports: https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers you'll want to avoid reusing anything with an "official" IANA status. Good alternatives for port 443 are 2443 and 8443, as those are available and easy to remember.

This works really well, and seems like a really useful feature for FCP. The only issue I see is for something like the speedtest plugin: https://github.com/dmacias72/unRAID-plugins/blob/master/plugins/speedtest.plg which installs different versions of python depending on the version of unRAID: <FILE Name="&plgPATH;/python-2.7.14-x86_64-1.txz" Min="6.4" Run="upgradepkg --install-new"> <FILE Name="&plgPATH;/python-2.7.13a-x86_64-2.txz" Min="6.2" Max="6.3.99" Run="upgradepkg --install-new"> <FILE Name="&plgPATH;/python-2.7.9-x86_64-1.txz" Max="6.1.99" Run="/sbin/upgradepkg --install-new"> Currently this script tests all three of them: speedtest: Testing /boot/config/plugins/speedtest/python-2.7.14-x86_64-1.txz... Passed speedtest: Testing /boot/config/plugins/speedtest/python-2.7.13a-x86_64-2.txz... Passed speedtest: /boot/config/plugins/speedtest/python-2.7.9-x86_64-1.txz included in plugin, but not present on flash drive I wouldn't really want an FCP warning about a missing 6.1 package, can it evaluate the min/max attributes and only test the one that applies? I suppose it could potentially tell you to delete the older packages too.