mifronte

After updating to 6.10.3 from 6.9.2., my SSL and https connection is now broken. I am getting an invalid certificate and my SSH key is not being accepted. I self-signed my own certificate using my pfSense. I have a feeling the update overwrote the appropriate files for SSH and HTTPS. Unfortunately, it has been a few years since I set up the SSH keys and HTTPS certificates so I don't know which files I should be looking at.

Would anyone know why this Unifi controller (V5.14.23) docker container would be trying to access something at the stretchoid.com domain? I noticed a log entry in my firewall that this container is trying to access this domain.

Woo hoo! Upgraded from 6.8.3 to 6.9.1 without any noticeable issues for now. There go my 357 days of uptime It was really touch and go there waiting for bzroot to load. It seems to get longer with every upgrade.

I do have Chromecasts and Google speakers on my network. Was the firmware prior to 4.3.24.11355 (4.3.21.11325) stable?

Thanks @Hoopster. @PeteAsking, I was able to successfully update to Controller 5.14.23 without any issues by first upgrading to 5.10.24. The database was upgraded by 5.10.24 prior to upgrading to 5.14.23. All my APs (1 local, 5 remote) showed up without issues. @Hoopster, Would you happen to know what would be a rock solid firmware for the APs to match Controller 5.14.23?

I'm on LTS (5.6) and would like to go to 5.14. This is a very long thread, can you point to or summarize the interim steps needed? I will go back and look for the actual posts, but this would serve as a cross reference to make sure I got everything correct. Thanks. Update: So to go from LTS (5.6) I would change the Repository as follows: Upgrade from LTS (5.6) to 5.10.24-ls21 Currently: linuxserver/unifi-controller:LTS Change to: linuxserver/unifi-controller:5.10.24-ls21 Then upgrade from 5.10.24-ls21 to 5.14.23-ls26 change Repository field to linuxserver/unifi-controller:5.14.23-ls76 Does that sound right?

I just updated this docker container by reinstalling it. I am running the LTS version. However, when reinstalling the container, my firewall intercepted the container trying to reach zg-0312c-421.stretchoid.com Anyone know what this is?

Thanks for the report. Now I know how to proceed when I decide to update.

The server has a DHCP IP reservation to receive the same IP. However, the issue was with timing between the bonded interface being ready and unRAID requesting the DHCP reservation. If the bonded interface is not ready when unRAID request the DHCP reservation, then unRAID assigns an IP of 169.x.x.x which is not part of my network.

The last two updates had problems if the server was configured to use DHCP and LACP where it could not get an IP during reboot so it assigned itself a 169.x.x.x IP. Has anyone successfully upgraded with the server being configured to use DHCP and LACP (bonded interfaces) or knows if this issue has been resolved?

If all you have is the AP, then all you had to do was configure the two WiFi Networks and assign one a VLAN ID. The Network settings in the UniFi controller does nothing if you do not use UBNT gateway products.

I am running pfSense and I used the UniFi Controller SW to tag my guest WiFi with a different VLAN tag from my main WIFI. My pfSense handles all the networking services for each WiFi network. I do have a smart switch between the AP and pfSense, so my AP is not plugged directly into my pfSense.

So I added the "inet restart" to the 'go' file and rebooted to test and it did not work. So I tried running the command through the console with the same result. It only worked after I first ran "inet" to clear the current 169.x.x.x IP and then "inet restart" got the correct IP from my DHCP. I did logged out between running the two commands just to see my current IP assignment on the login console since I did not know the command to show my current network configurations. Funny thing was, I was just trying to get help on the inet command and accidentally ran it without any arguments. So if I was to use the 'go' file, what would be a more elegant set of commands to clear the current IP assignment and request a new one from DHCP?

Well disabling the USB Legacy Support in the BIOS for the X7SBE was a major futile exercise. Not only did my system not boot from the unRAID USB flash drive, but I also lost IPMI keyboard control. Had to plug in an acutal PS2 keyboard to get back in the BIOS.

The only USB related settings in the BIOS is Legacy USB Support (Enabled or Disabled). It is currently Enabled, if I set this to Disabled, would it force the USB ports to always operate at 2.0? The motherboard specs says it supports USB 2.0 and 1.1. The only other related USB settings in the BIOS is to allow the back panel USB ports to wake up the system.

S The problem is not with the system boot, but with loading bzroot. I read a post somewhere that loading bzroot in UEFI is quick, but in Legacy is super slow. Anyway, I found out that my X7SBE with the Phoenix 1.2a BIOS does not support UEFI. So I am stuck with a slow loading of bzroot.

Would anyone happens to know if the Supermicro X7SBE with Phoenix BIOS 1.2a supports UEFI boot mode? I could not see anything in the BIOS to indicate so, but I was hopping that it naturally supports it. Haven't been able to find any documentation regarding UEFI support for the X7SBE either. I am hoping to speed up the loading of unRAID at boot time.

Muchas gracias!

That explanation sounds reasonable since running the command inet restart at the console after the server boots gets the correct IP. Would it be a good idea for me to put this command in my go script file if I prefer to keep my server using DHCP to get all of its networking configuration (i.e. local DNS, gateway, IP address)?

Yeah, I did not see any release notes to see what were the changes. Also, do you have to delete the container? Can't one just click on the apply update link under the Docker tab?

My SG350 Cisco switch is a small business switch which uses a GUI interface and it does not use Cisco's IOS like the enterprise switches. So starting with 6.8.1, there must have been some changes in how the bond channel initializes and when DHCP client requests are made? I can definitely configure unRAID with a fixed IP, but this means starting at unRAID 6.8.1, it no longer can support DHCP or is this a bug that can be fixed?

Not quite sure what "race condition" means. I do have the DHCP server configured to give my unRAID server a static IP. I guess the last resort is to hard code in the IP address into the unRAID settings if there is no other solution.

Each port is set to auto negotiate. The LAG is using LACP and auto negotiate too. I don't see any "active" mode settings.

Yes, my Cisco SG350 switch supports 802.3ad. It has always worked prior to 6.8.1 and it is working now after I ran the command inet restart after the server boots. Starting with 6.8.1, I started having problems with the server not acquiring an IP address during boot. Actually with 6.8.1, it happened the first reboot after updating. Then it worked when I rebooted the server again. Now with 6.8.2, the server does not obtain an IP address during the boot process at all. Could it be a timing issue and the boot process does not allow enough time to obtain an IP address before defaulting to the 169.x.x.x? Something starting with 6.8.1 that is giving me this problem. I would rather not have to change the bonding protocol because I do not want to mess with my switch LAG configuration since my current bonding setup has been working flawlessly for years.

I am currently running with the LTS tag (Unifi Controller 5.6.42. I noticed in unRAID that the docker container has an update available. Is there a place where I can read what the update contains?