mifronte

Members
  • Posts

    423
  • Joined

  • Last visited

Posts posted by mifronte

  1. 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?

    • Like 1
  2. On 12/14/2020 at 2:34 PM, Hoopster said:

    SIf you were going from LTS (5.6), to 5.14, there would be some necessary interim steps as outlined earlier in this thread.

     

    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?

    • Thanks 1
  3. 23 hours ago, GeekMajic said:

    I always recommend using static IP for servers, either set on the server or with DCHP reservation. I fear what would happen if the unraid box got a new IP but the dockers weren't aware until they were restarted again.

    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.

  4. 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?

  5. 19 minutes ago, dnLL said:

     

    My AP is directly behind pfSense, all I had to do on the UniFi controller is basically to create 2 networks in 2 different subnets, ...

    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.

  6. On 2/28/2020 at 4:31 AM, dnLL said:

    Bonus question not really related to the docker: I assume this software with one AP plugged into my pfSense box will allow me to have pretty much complete control over my WiFi? I want guests to be on a separate SSID and ideally a different network subnet to restrict their access to the local network and I want pfSense to handle most of it (DHCP/DNS/firewall/etc) if possible

    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.

  7. On 2/6/2020 at 8:51 AM, bonienl said:

    As a temporary solution you can add the command to the 'go' file

     

    As a permanent solution I've made an update to deal with the timing. Will come in the next version.

    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?

  8. 4 hours ago, johnnie.black said:

    Check that USB ports are set to 2.0, USB 1.0 is very slow booting, like mentioned UEFI it's not faster. 

    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.

  9. S

    4 hours ago, Benson said:

    I can't found UEFI would boot faster then Legacy. If longer boot was due to storage controller optrom active, you should try disable it in mainboard BIOS.

     

    Note : I disable it in CSM or UEFI, so no storage optrom enable or scanning disk during system boot.

    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.

  10. 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.

  11. 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)?

  12. 6 hours ago, lordbob75 said:

    Since the GitHub post didn't specify anything for UnRAID specifically, I'll post it here to confirm it for anyone who's unsure.

     

    Simply delete your current container (and image).

    Reinstall the container, and choose the Default (or Latest).

    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?

  13. 4 minutes ago, bonienl said:

    When you configure an interface and make it a member of a port-channel, you would do something like

    
    channel-group 1 mode active

     

    DHCP is trying to obtain an IP address while at the same time the bond channel is initializing.

    This results in a "no answer" for DHCP which gives the 169.254.x.x address assignment.

     

    When you set a fixed IP address on the server (something I recommend), there is no more dependency and it doesn't matter how long the bond initialization takes.

     

    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?

  14. 8 minutes ago, bonienl said:

    You could also change to a static IP address and avoid any race condition.

    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.

  15. 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.

    • Like 1