PatrickK

I have the same issue being reported here. My unifi controller (v5.6.37) could not connect with the AP's (v3.9.27.8537) or the other way around once the unifi docker controller was updated. This happened several times in the last few weeks, every time the unifi docker was updated. The unifi docker was set to bridged network mode. The AP's were set via set-inform to a FQDN; "htttp://xxxx.xxxxx.xx:8080/inform". Which is reachable and works to adapt new remote AP's. I currently don't have AP's on a remote site running. But I have tested it a week ago since I plan to help out and manage remote sites running Ubiquiti hardware. Once the unifi docker was updated yesterday, I verified the set-inform address configured on the AP's using command "info". For some reason it was set to the docker's NAT'ed IP 172.17.0.5 instead of the previously set FQDN. There is no DNS entry called unifi pointing towards IP 172.17.0.5, so the setting must have come from the unifi controller at some point in time. I read in this thread that the bridged IP doesn't work well, so I switched to custom. I set it to 192.168.123.3 in the 192.168.123.0/24 range of my UnRaid server (IP 192.168.123.10). Once set and the unfi docker came online, the AP's were all connected. So, that works like a charm. Curious though I verified the set-inform address again on the AP's. It seems it is set to the new IP; "http://192.168.123.3:8080/inform". It seems that the controller changes the set-inform on at least local hardware. I currently don't have remote AP's online, so I don't know that it will do with those. Inside the unifi controller, the setting "hostname/ip" is set to the FQDN address and not to the old or new IP. The Ubiquiti cloud connect feature also works after the IP change without any issues. The AP's are all UAP-AC-Lite's. No other hardware is connected at this point. I have another 3x AP's configured, which will be installed in the next couple days on a remote site. I will have to test them again before deploying them and I'm curious what a future controller update will do to them. I will keep you posted when I have any relevant information.

I've also been wondering on ways to speed up XBMC/Kodi using centralized databases profiles. In my experience even a wired network connection running XBMC on an Apple TV2 is too slow to load the many small files (Thumbnails) and read the MySQL database entries in an acceptable time frame. Well then maybe something like an Rsync between a central and local thumbnails folder would be a better solution ? Assuming there is enough local storage available. It seems that the thumbnail folder size can be held in check using the Texture Cache Maintenance utility. If that is no option, I guess we are better off dropping centralized thumbnails all together and only use the MySQL database to synchronize database and profile. No ?

I have solved my cross flashing issue. But not after my favorite mainboard brand Gigabyte disappointed me. I learned how easy it is to make a USB pendrive EFI bootable. Just drop this binary into that flash drive FAT's root directory and rename it to <shellx64.efi>. Also, from Roderick W. Smith's site rodsbook.com I learned that Gigabyte's Hybrid EFI implementation is one of the worst that Mr Smith has encountered. So, if you have a Gigabyte mainboard forget EFI Shell, it probably won't work. It has cost me several hours today. I eventually solved it by inserting the LSI 9240-8i into the PCI Express x16 slot of an Asrock H81 Pro BTC mainboard. (A mainboard I almost forgot I still own. A relic from my scrypt mining days.) After entering the BIOS and going to the last menu "Exit", I selected the bottom option "Launch EFI Shell from filesystem device". It gave me a <SHELL> prompt. I selected my USB pendrive by typing "FS0:". I browsed to the location of my sas2flash.efi, 2118it.bin and mptsas2.rom files and executed the following two commands; sas2flash -o -f 2118it.bin -b mptsas2.rom sas2flash -o -sasadd 500605b0xxxxxxxx (replace the xx's with the SAS address from your card) Identical to BetaQuasi's M1015 Cross flashing instructions except that I used <sas2flash.efi> instead of <sas2flsh.exe>. Unraid 5.0.5 has identified the card and the attached drives. I'm a happy camper ! ;-)

First of all thank you all for the information provided on this forum. I have a LSI 9240-8i that I'm trying to downgrade to IT mode using the 9211-8i P19 firmware as described on the first page and the M1015 Cross flashing message from BetaQuasi. I managed to execute the megarec command listed below and reboot; megarec -writesbr 0 sbrempty.bin megarec -cleanflash 0 But when trying the sas2flsh commands I receive the error message "ERROR: Failed to initialize PAL" aka The PAL error. Another mainboard is not an option and I do not have an UEFI Shell option on my Gigabyte Z87X-UD3H mainboard, at least not that I'm aware off. I tried to create an bootable USB stick that would boot from UEFI, but I did not succeed yet. At the moment I'm trying a LinuxMint USB and the SAS2FLSH for Linux after spending hours looking for a UEFI boot option together with the SAS2FLASH.efi file. Tips and guides are welcome. Thank you in advance !

Thank you garycase !

Hello, I am new to unraid and I'm in the proces of selecting hardware for a future server build. It have one specific question; Does the drive cage impact the transfer speed between the controller and hard drive ? If the answer is yes; Are there more components that might have an negative impact between a SATA III (6 Gbit) controller and SATA III (6 Gbit) hard drive ? SATA cables do not seem to impact the transfer speed according to this article.