[Bug]: 5.14.x (beta & GA) does not start up

[IAmKonni]

🚨If you're experiencing this issue🚨

Feel free to add to this thread but please also post on the TP-Link Forums in this thread. There is only so much I can do and this appears to be a software related issue that I can't do anything about. If 5.14 never successfully ran for you, you can manually remove the version check file and specify the 5.13 tag to get back to a running controller. See this post in this thread for more info.

I will update this first thread as more information becomes available from TP-Link as well but subscribing to that forum thread would be a good idea too.

Update 2024-07-26: There is now a beta version available where the issue appears to be fixed. Images have been pushed and the tags are now available on Docker Hub. I would only suggest running the beta if you know what you're doing when it comes to running beta software or if you're stuck with a broken controller that can't be downgraded to 5.13 because 5.14 has already started at some point. If you're not having problems, I would suggest staying on 5.13.

The image tag is beta-5.14.30.7 for multi-arch and then there are specific tags for each architecture + the build with chromium if you use the report generation feature.

-mbentley

---

Controller Version

5.14.0.11

Describe the Bug

I switched from tag 5.13 to beta to test the newest pre-release. I never had any problems in updating to newer versions, this is the very first time i'm facing a problem. The controller does not start up, it runs into a boot loop (see logs).

Expected Behavior

Starting like always. =)

Steps to Reproduce

Change tag in compose file from 5.13 to beta and run docker-compose up -d

How You're Launching the Container

version: "3"

services:
  omada-controller:
    container_name: omada-controller
    image: mbentley/omada-controller:beta
    ports:
      - "8043:8043/tcp"
      - "443:443/tcp"
      - "8488:8488/tcp"
      - "8443:8443/tcp"
      - "8483:8483/tcp"
      - "29810:29810/udp"
      - "29811:29811"
      - "29812:29812"
      - "29813:29813"
      - "29814:29814"

    environment:
      MANAGE_HTTP_PORT: 8488
      MANAGE_HTTPS_PORT: 8443
      PORTAL_HTTP_PORT: 8488
      PORTAL_HTTPS_PORT: 8483
      SHOW_SERVER_LOGS: 'true'
      SHOW_MONGODB_LOGS: 'false'
      SSL_CERT_NAME: 'tls.crt'
      SSL_KEY_NAME: 'tls.key'
      TZ: 'Europe/Berlin'
    volumes:
      - ./data:/opt/tplink/EAPController/data
      - ./work:/opt/tplink/EAPController/work
      - ./logs:/opt/tplink/EAPController/logs
    restart: unless-stopped

Container Logs

03-25-2024 18:32:38.365 ERROR [main] [] c.t.s.o.s.t.SpringBootStartUpTask(): Cannot retry start up springboot. reson:Error creating bean with name 'com.tplink.smb.omada.identityaccess.domain.model.openapi.c.q': Unsatisfied dependency expressed through field 'e'; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'com.tplink.smb.omada.identityaccess.port.common.a.a': Unsatisfied dependency expressed through field 'c'; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'com.tplink.smb.omada.identityaccess.port.common.e.a': Unsatisfied dependency expressed through field 'b'; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'com.tplink.smb.omada.identityaccess.b.p': Unsatisfied dependency expressed through field 'm'; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'com.tplink.smb.omada.identityaccess.domain.model.user.A': Unsatisfied dependency expressed through field 'c'; nested exception is org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'com.tplink.smb.omada.identityaccess.port.mongo.adaptor.persistence.tenant.a': Bean with name 'com.tplink.smb.omada.identityaccess.port.mongo.adaptor.persistence.tenant.a' has been injected into other beans [com.tplink.smb.omada.identityaccess.domain.model.d.q] in its raw version as part of a circular reference, but has eventually been wrapped. This means that said other beans do not use the final version of the bean. This is often the result of over-eager type matching - consider using 'getBeanNamesForType' with the 'allowEagerInit' flag turned off, for example.
03-25-2024 18:32:38.365 ERROR [main] [] c.t.s.o.s.t.FailExitTask(): Failed to start omada controller, going to exit
03-25-2024 18:32:38.366 INFO [Thread-0] [] c.t.s.o.s.OmadaBootstrap(): Failed to shutdown customThread.
java.lang.ExceptionInInitializerError: null
    at com.tplink.smb.omada.common.concurrent.thread.a.a(SourceFile:243) ~[omada-common-5.14.0.11.jar:5.14.0.11]
    at com.tplink.smb.omada.starter.OmadaBootstrap.b(SourceFile:195) ~[local-starter-5.14.0.11.jar:5.14.0.11]
    at com.tplink.smb.omada.starter.OmadaLinuxMain.b(SourceFile:87) ~[local-starter-5.14.0.11.jar:5.14.0.11]
    at java.lang.Thread.run(Thread.java:840) [?:?]
Caused by: java.lang.IllegalStateException: org.springframework.boot.web.servlet.context.AnnotationConfigServletWebServerApplicationContext@398f2bd3 has not been refreshed yet
    at org.springframework.context.support.AbstractApplicationContext.assertBeanFactoryActive(AbstractApplicationContext.java:1147) ~[spring-context-5.3.30.jar:5.3.30]
    at org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:1159) ~[spring-context-5.3.30.jar:5.3.30]
    at com.tplink.smb.omada.common.spring.a.a(SourceFile:28) ~[omada-common-5.14.0.11.jar:5.14.0.11]
    at com.tplink.smb.omada.common.concurrent.thread.a$a.<clinit>(SourceFile:55) ~[omada-common-5.14.0.11.jar:5.14.0.11]
    ... 4 more
INFO: Validating user/group (omada:omada) exists with correct UID/GID (508:508)
INFO: Group (omada) exists; skipping creation
INFO: User (omada) exists; skipping creation
INFO: Time zone set to 'Europe/Berlin'
INFO: Value of 'manage.http.port' already set to 8488 in omada.properties
INFO: Value of 'manage.https.port' already set to 8443 in omada.properties
INFO: Value of 'portal.http.port' already set to 8488 in omada.properties
INFO: Value of 'portal.https.port' already set to 8483 in omada.properties
INFO: Value of 'port.adopt.v1' already set to 29812 in omada.properties
INFO: Value of 'port.app.discovery' already set to 27001 in omada.properties
INFO: Value of 'port.upgrade.v1' already set to 29813 in omada.properties
INFO: Value of 'port.manager.v1' already set to 29811 in omada.properties
INFO: Value of 'port.manager.v2' already set to 29814 in omada.properties
INFO: Value of 'port.discovery' already set to 29810 in omada.properties
INFO: Value of 'port.transfer.v2' already set to 29815 in omada.properties
INFO: Value of 'port.rtty' already set to 29816 in omada.properties
INFO: Value of 'mongo.external' already set to false in omada.properties
INFO: Value of 'eap.mongod.uri' already set to mongodb://127.0.0.1:27217/omada in omada.properties
INFO: Version check passed; image version (5.14.0.11) >= the last version ran (5.14.0.11); writing image version to last ran file...
INFO: userland/kernel check passed
INFO: Starting Omada Controller as user omada
03-25-2024 18:32:47.525 INFO [main] [] c.t.s.o.s.OmadaLinuxMain(): record: start the omada controller
03-25-2024 18:32:47.528 INFO [main] [] c.t.s.o.s.OmadaLinuxMain(): record: set property finished
03-25-2024 18:32:47.530 INFO [main] [] c.t.s.o.s.OmadaLinuxMain(): record: configure log finished
03-25-2024 18:32:47.532 INFO [main] [] c.t.s.o.s.OmadaBootstrap(): record: bootstrap prepare
03-25-2024 18:32:47.538 INFO [log4j-thread] [] c.t.s.o.c.o.a.b(): success to load configuration omada.properties
03-25-2024 18:32:47.539 INFO [log4j-thread] [] c.t.s.o.c.o.OmadacType(): omadacType: Local Controller
03-25-2024 18:32:47.556 INFO [main] [] c.t.s.o.s.OmadaBootstrap(): going to start local mongod.
03-25-2024 18:32:50.068 INFO [main] [] c.t.s.o.s.s.b(): mongodb process id is 155
03-25-2024 18:32:50.071 ERROR [main] [] c.t.s.f.c.FacadeUtils(): facadeMsgEnable is not enable, msg: Mongo DB server started
03-25-2024 18:32:50.071 INFO [main] [] c.t.s.o.s.s.b(): Mongo DB server started
03-25-2024 18:32:50.327 INFO [main] [] c.t.s.o.s.OmadaBootstrap(): record: bootstrap record finished
03-25-2024 18:32:50.327 INFO [main] [] c.t.s.o.s.OmadaBootstrap(): record: bootstrap startup
03-25-2024 18:32:50.380 INFO [main] [] c.t.s.o.s.OmadaBootstrap(): record: start run omada tasks
03-25-2024 18:32:50.380 INFO [main] [] c.t.s.o.s.t.SpringBootStartUpTask(): record: task SpringBootStartupTask start
  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
  '  |____| .__|_| |_|_| |_\__, | / / / /
 =========|_|==============|___/=/_/_/_/
 :: Spring Boot ::               (v2.7.17)
03-25-2024 18:32:50.837 INFO [main] [] c.t.s.o.s.OmadaLinuxMain(): Starting OmadaLinuxMain v5.14.0.11 using Java 17.0.10 on 3c8dd90b3952 with PID 1 (/opt/tplink/EAPController/lib/local-starter-5.14.0.11.jar started by omada in /opt/tplink/EAPController/lib)
03-25-2024 18:32:50.839 INFO [main] [] c.t.s.o.s.OmadaLinuxMain(): No active profile set, falling back to 1 default profile: "default"
03-25-2024 18:32:56.974 WARN [main] [] o.s.d.c.CustomConversions(): Registering converter from class java.time.LocalDateTime to class org.joda.time.LocalDateTime as reading converter although it doesn't convert from a store-supported type; You might want to check your annotation setup at the converter implementation
03-25-2024 18:32:58.664 WARN [main] [] o.s.b.w.s.c.AnnotationConfigServletWebServerApplicationContext(): Exception encountered during context initialization - cancelling refresh attempt: org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'com.tplink.smb.omada.identityaccess.domain.model.openapi.c.q': Unsatisfied dependency expressed through field 'e'; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'com.tplink.smb.omada.identityaccess.port.common.a.a': Unsatisfied dependency expressed through field 'c'; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'com.tplink.smb.omada.identityaccess.port.common.e.a': Unsatisfied dependency expressed through field 'b'; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'com.tplink.smb.omada.identityaccess.b.p': Unsatisfied dependency expressed through field 'm'; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'com.tplink.smb.omada.identityaccess.domain.model.user.A': Unsatisfied dependency expressed through field 'c'; nested exception is org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'com.tplink.smb.omada.identityaccess.port.mongo.adaptor.persistence.tenant.a': Bean with name 'com.tplink.smb.omada.identityaccess.port.mongo.adaptor.persistence.tenant.a' has been injected into other beans [com.tplink.smb.omada.identityaccess.domain.model.d.q] in its raw version as part of a circular reference, but has eventually been wrapped. This means that said other beans do not use the final version of the bean. This is often the result of over-eager type matching - consider using 'getBeanNamesForType' with the 'allowEagerInit' flag turned off, for example.
03-25-2024 18:32:58.700 ERROR [main] [] o.s.b.SpringApplication(): Application run failed
org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'com.tplink.smb.omada.identityaccess.domain.model.openapi.c.q': Unsatisfied dependency expressed through field 'e'; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'com.tplink.smb.omada.identityaccess.port.common.a.a': Unsatisfied dependency expressed through field 'c'; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'com.tplink.smb.omada.identityaccess.port.common.e.a': Unsatisfied dependency expressed through field 'b'; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'com.tplink.smb.omada.identityaccess.b.p': Unsatisfied dependency expressed through field 'm'; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'com.tplink.smb.omada.identityaccess.domain.model.user.A': Unsatisfied dependency expressed through field 'c'; nested exception is org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'com.tplink.smb.omada.identityaccess.port.mongo.adaptor.persistence.tenant.a': Bean with name 'com.tplink.smb.omada.identityaccess.port.mongo.adaptor.persistence.tenant.a' has been injected into other beans [com.tplink.smb.omada.identityaccess.domain.model.d.q] in its raw version as part of a circular reference, but has eventually been wrapped. This means that said other beans do not use the final version of the bean. This is often the result of over-eager type matching - consider using 'getBeanNamesForType' with the 'allowEagerInit' flag turned off, for example.
    at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.resolveFieldValue(AutowiredAnnotationBeanPostProcessor.java:713) ~[spring-beans-5.3.30.jar:5.3.30]
    at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.inject(AutowiredAnnotationBeanPostProcessor.java:693) ~[spring-beans-5.3.30.jar:5.3.30]
    at org.springframework.beans.factory.annotation.InjectionMetadata.inject(InjectionMetadata.java:119) ~[spring-beans-5.3.30.jar:5.3.30]
    at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessProperties(AutowiredAnnotationBeanPostProcessor.java:408) ~[spring-beans-5.3.30.jar:5.3.30]
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1431) ~[spring-beans-5.3.30.jar:5.3.30]
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:619) ~[spring-beans-5.3.30.jar:5.3.30]
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:542) ~[spring-beans-5.3.30.jar:5.3.30]
    at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:335) ~[spring-beans-5.3.30.jar:5.3.30]
    at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:234) ~[spring-beans-5.3.30.jar:5.3.30]
    at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:333) ~[spring-beans-5.3.30.jar:5.3.30]
    at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:208) ~[spring-beans-5.3.30.jar:5.3.30]
    at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:955) ~[spring-beans-5.3.30.jar:5.3.30]
    at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:921) ~[spring-context-5.3.30.jar:5.3.30]
    at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:583) ~[spring-context-5.3.30.jar:5.3.30]
    at org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext.refresh(ServletWebServerApplicationContext.java:147) ~[spring-boot-2.7.17.jar:2.7.17]
    at org.springframework.boot.SpringApplication.refresh(SpringApplication.java:732) ~[spring-boot-2.7.17.jar:2.7.17]
    at org.springframework.boot.SpringApplication.refreshContext(SpringApplication.java:409) ~[spring-boot-2.7.17.jar:2.7.17]
    at org.springframework.boot.SpringApplication.run(SpringApplication.java:308) ~[spring-boot-2.7.17.jar:2.7.17]
    at org.springframework.boot.SpringApplication.run(SpringApplication.java:1300) ~[spring-boot-2.7.17.jar:2.7.17]
    at org.springframework.boot.SpringApplication.run(SpringApplication.java:1289) ~[spring-boot-2.7.17.jar:2.7.17]
    at com.tplink.smb.omada.starter.task.SpringBootStartUpTask.execute(SourceFile:33) ~[local-starter-5.14.0.11.jar:5.14.0.11]
    at com.tplink.smb.omada.starter.task.c.a(SourceFile:20) ~[local-starter-5.14.0.11.jar:5.14.0.11]
    at com.tplink.smb.omada.starter.OmadaBootstrap.f(SourceFile:356) ~[local-starter-5.14.0.11.jar:5.14.0.11]
    at com.tplink.smb.omada.starter.OmadaLinuxMain.a(SourceFile:99) ~[local-starter-5.14.0.11.jar:5.14.0.11]
    at com.tplink.smb.omada.starter.OmadaLinuxMain.main(SourceFile:42) ~[local-starter-5.14.0.11.jar:5.14.0.11]
Caused by: org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'com.tplink.smb.omada.identityaccess.port.common.a.a': Unsatisfied dependency expressed through field 'c'; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'com.tplink.smb.omada.identityaccess.port.common.e.a': Unsatisfied dependency expressed through field 'b'; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'com.tplink.smb.omada.identityaccess.b.p': Unsatisfied dependency expressed through field 'm'; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'com.tplink.smb.omada.identityaccess.domain.model.user.A': Unsatisfied dependency expressed through field 'c'; nested exception is org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'com.tplink.smb.omada.identityaccess.port.mongo.adaptor.persistence.tenant.a': Bean with name 'com.tplink.smb.omada.identityaccess.port.mongo.adaptor.persistence.tenant.a' has been injected into other beans [com.tplink.smb.omada.identityaccess.domain.model.d.q] in its raw version as part of a circular reference, but has eventually been wrapped. This means that said other beans do not use the final version of the bean. This is often the result of over-eager type matching - consider using 'getBeanNamesForType' with the 'allowEagerInit' flag turned off, for example.
    at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.resolveFieldValue(AutowiredAnnotationBeanPostProcessor.java:713) ~[spring-beans-5.3.30.jar:5.3.30]
    at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.inject(AutowiredAnnotationBeanPostProcessor.java:693) ~[spring-beans-5.3.30.jar:5.3.30]
    at org.springframework.beans.factory.annotation.InjectionMetadata.inject(InjectionMetadata.java:119) ~[spring-beans-5.3.30.jar:5.3.30]
    at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessProperties(AutowiredAnnotationBeanPostProcessor.java:408) ~[spring-beans-5.3.30.jar:5.3.30]
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1431) ~[spring-beans-5.3.30.jar:5.3.30]
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:619) ~[spring-beans-5.3.30.jar:5.3.30]
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:542) ~[spring-beans-5.3.30.jar:5.3.30]
    at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:335) ~[spring-beans-5.3.30.jar:5.3.30]
    at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:234) ~[spring-beans-5.3.30.jar:5.3.30]
    at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:333) ~[spring-beans-5.3.30.jar:5.3.30]
    at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:208) ~[spring-beans-5.3.30.jar:5.3.30]
    at org.springframework.beans.factory.config.DependencyDescriptor.resolveCandidate(DependencyDescriptor.java:276) ~[spring-beans-5.3.30.jar:5.3.30]
    at org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:1391) ~[spring-beans-5.3.30.jar:5.3.30]
    at org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:1311) ~[spring-beans-5.3.30.jar:5.3.30]
    at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.resolveFieldValue(AutowiredAnnotationBeanPostProcessor.java:710) ~[spring-beans-5.3.30.jar:5.3.30]

MongoDB Logs

2024-03-25T18:29:13.220+0100 I STORAGE  [signalProcessingThread] shutdown: removing fs lock...
2024-03-25T18:29:13.220+0100 I CONTROL  [signalProcessingThread] now exiting
2024-03-25T18:29:13.220+0100 I CONTROL  [signalProcessingThread] shutting down with code:0
2024-03-25T18:29:33.908+0100 I CONTROL  [main] ***** SERVER RESTARTED *****
2024-03-25T18:29:33.919+0100 I CONTROL  [initandlisten] MongoDB starting : pid=175 port=27217 dbpath=../data/db 64-bit host=28242437eafe
2024-03-25T18:29:33.920+0100 I CONTROL  [initandlisten] db version v3.6.8
2024-03-25T18:29:33.920+0100 I CONTROL  [initandlisten] git version: 8e540c0b6db93ce994cc548f000900bdc740f80a
2024-03-25T18:29:33.920+0100 I CONTROL  [initandlisten] OpenSSL version: OpenSSL 1.1.1f  31 Mar 2020
2024-03-25T18:29:33.920+0100 I CONTROL  [initandlisten] allocator: tcmalloc
2024-03-25T18:29:33.920+0100 I CONTROL  [initandlisten] modules: none
2024-03-25T18:29:33.920+0100 I CONTROL  [initandlisten] build environment:
2024-03-25T18:29:33.920+0100 I CONTROL  [initandlisten]     distarch: x86_64
2024-03-25T18:29:33.920+0100 I CONTROL  [initandlisten]     target_arch: x86_64
2024-03-25T18:29:33.920+0100 I CONTROL  [initandlisten] options: { net: { bindIp: "127.0.0.1", port: 27217 }, processManagement: { pidFilePath: "../data/mongo.pid" }, storage: { dbPath: "../data/db", journal: { enabled: true } }, systemLog: { destination: "file", logAppend: true, path: "../logs/mongod.log" } }
2024-03-25T18:29:33.920+0100 I -        [initandlisten] Detected data files in ../data/db created by the 'wiredTiger' storage engine, so setting the active storage engine to 'wiredTiger'.
2024-03-25T18:29:33.920+0100 I STORAGE  [initandlisten]
2024-03-25T18:29:33.920+0100 I STORAGE  [initandlisten] ** WARNING: Using the XFS filesystem is strongly recommended with the WiredTiger storage engine
2024-03-25T18:29:33.920+0100 I STORAGE  [initandlisten] **          See http://dochub.mongodb.org/core/prodnotes-filesystem
2024-03-25T18:29:33.920+0100 I STORAGE  [initandlisten] wiredtiger_open config: create,cache_size=11315M,session_max=20000,eviction=(threads_min=4,threads_max=4),config_base=false,statistics=(fast),cache_cursors=false,compatibility=(release="3.0",require_max="3.0"),log=(enabled=true,archive=true,path=journal,compressor=snappy),file_manager=(close_idle_time=100000),statistics_log=(wait=0),verbose=(recovery_progress),
2024-03-25T18:29:34.589+0100 I STORAGE  [initandlisten] WiredTiger message [1711387774:589205][175:0x7f1f3c986ac0], txn-recover: Main recovery loop: starting at 232/36004352
2024-03-25T18:29:34.638+0100 I STORAGE  [initandlisten] WiredTiger message [1711387774:638685][175:0x7f1f3c986ac0], txn-recover: Recovering log 232 through 233
2024-03-25T18:29:34.662+0100 I STORAGE  [initandlisten] WiredTiger message [1711387774:662948][175:0x7f1f3c986ac0], txn-recover: Recovering log 233 through 233
2024-03-25T18:29:34.691+0100 I STORAGE  [initandlisten] WiredTiger message [1711387774:691597][175:0x7f1f3c986ac0], txn-recover: Set global recovery timestamp: 0
2024-03-25T18:29:34.857+0100 I CONTROL  [initandlisten]
2024-03-25T18:29:34.857+0100 I CONTROL  [initandlisten] ** WARNING: Access control is not enabled for the database.
2024-03-25T18:29:34.857+0100 I CONTROL  [initandlisten] **          Read and write access to data and configuration is unrestricted.
2024-03-25T18:29:34.857+0100 I CONTROL  [initandlisten]
2024-03-25T18:29:35.907+0100 I FTDC     [initandlisten] Initializing full-time diagnostic data capture with directory '../data/db/diagnostic.data'
2024-03-25T18:29:35.908+0100 I NETWORK  [initandlisten] waiting for connections on port 27217
2024-03-25T18:29:36.575+0100 I NETWORK  [listener] connection accepted from 127.0.0.1:41382 #1 (1 connection now open)
2024-03-25T18:29:36.575+0100 I NETWORK  [listener] connection accepted from 127.0.0.1:41380 #2 (2 connections now open)

Additional Context

The mongo db log is the first iteration after switching to 5.14 beta. There are more following Exceptions and stack traces in the log, but all seem to be of missing dependencies.

org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'com.tplink.smb.omada.identityaccess.domain.model.user.A': Unsatisfied dependency expressed through field 'c'; nested exception is org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'com.tplink.smb.omada.identityaccess.port.mongo.adaptor.persistence.tenant.a': Bean with name 'com.tplink.smb.omada.identityaccess.port.mongo.adaptor.persistence.tenant.a' has been injected into other beans [com.tplink.smb.omada.identityaccess.domain.model.d.q] in its raw version as part of a circular reference, but has eventually been wrapped. This means that said other beans do not use the final version of the bean. This is often the result of over-eager type matching - consider using 'getBeanNamesForType' with the 'allowEagerInit' flag turned off, for example.

org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'com.tplink.smb.omada.identityaccess.port.mongo.adaptor.persistence.tenant.a': Bean with name 'com.tplink.smb.omada.identityaccess.port.mongo.adaptor.persistence.tenant.a' has been injected into other beans [com.tplink.smb.omada.identityaccess.domain.model.d.q] in its raw version as part of a circular reference, but has eventually been wrapped. This means that said other beans do not use the final version of the bean. This is often the result of over-eager type matching - consider using 'getBeanNamesForType' with the 'allowEagerInit' flag turned off, for example.

[CoronaExtra]

I can report the same problem

[mbentley]

I'll have to look into this when I am able to as I'm traveling now. Not immediately sure if there is just some java arg that needs to be set or what.

[IAmKonni]

No hurry, I'm totally fine with 5.13. :)

[mbentley]

OK, so at least when starting up a new controller directly on the beta 5.14.0.11, I don't have startup issues. I also started up a new 5.13, did a minimal setup of the controller and then switched it to the latest beta and I don't see a startup problem with that basic upgrade scenario. I don't run the betas on my home environment just because I need my home network to be stable.

From whoever it running into the issue:

• What architecture are you running - amd64, arm64, or armv7l? I've only tested amd64 and arm64 just now.
• Any idea what version of the controller you originally started with? I might need to check to see if this is something that comes up only due to upgrade issues
• Could you also provide the docker inspect <container-name-or-id> --format '{{json .Args}}' output for me? I just want to verify the container's command used.

[IAmKonni]

I'm running an amd64 architecture (Intel NUC 11). As far as I can remember I probably started with an 4.x version (maybe 4.2 or 4.3?) and updated them all iteratively (mostly i used "latest"-tag). Since you are offering beta versions I'm using distinct tags (e.g. "5.13").

docker inspect (now back on 5.13) says:

["/usr/bin/java","-server","-Xms128m","-Xmx1024m","-XX:MaxHeapFreeRatio=60","-XX:MinHeapFreeRatio=30","-XX:+HeapDumpOnOutOfMemoryError","-XX:HeapDumpPath=/opt/tplink/EAPController/logs/java_heapdump.hprof","-Djava.awt.headless=true","--add-opens","java.base/java.util=ALL-UNNAMED","-cp","/opt/tplink/EAPController/lib/*::/opt/tplink/EAPController/properties:","com.tplink.smb.omada.starter.OmadaLinuxMain"]

Should I run again with 5.14?

[mbentley]

Should I run again with 5.14?

No, that's ok. I just wanted to make sure that the CMD hadn't been modified from the default but since yours matches for 5.13, it would be fine for 5.14 regardless. Some tools used to manage containers will take the CMD from the image and hard code it to the container definition so if you update the image, it actually will not update the CMD. At least it helps eliminate that as a possible reason why it isn't starting.

[mbentley]

On a quick test, I did a basic deployment of a new controller and upgraded, skipping minor versions to hopefully reproduce it quickly:

mbentley/omada-controller:4.2
mbentley/omada-controller:4.4
mbentley/omada-controller:5.13
mbentley/omada-controller:beta

No such luck in this case. I will have to see if I can try every version it seems.

[mbentley]

Well I was hoping that going through all of the versions would help reproduce it but I went through all of these versions and the beta started correctly:

4.2, 4.3, 4.4, 5.0, 5.1, 5.3, 5.4, 5.5, 5.6, 5.7, 5.8, 5.9, 5.12, 5.13, beta

[IAmKonni]

I don't care too much about this beta, but I hope this won't be the same with 5.14 final, when it arrives. :) Maybe it has to do with some of my settings. In the worst case I have to do a new setup and start with a clean sheet. Thank you for all your efforts so far. That's not a matter of course.

[ruudkobes]

I can confirm the same issue: upgraded from the previous beta to this latest beta. After updating it fails to start with logs looking identical to @IAmKonni's above, same bean creation failure.

Starts and runs fine back on 5.13.

Running on AMD64.

Let me know if I can check something else which may help identify the problem.

[eblieb]

I stopped my 5.13 container and built a new container with docker run -d \ --name omada-controller-beta \ --stop-timeout 60 \ --restart unless-stopped \ --net host \ -e MANAGE_HTTP_PORT=8088 \ -v omada-data:/opt/tplink/EAPController/data \ -v omada-logs:/opt/tplink/EAPController/logs \ mbentley/omada-controller:beta

and it is running just fine.

[eblieb]

FYI a new beta was released. Waiting for the docker container to be updated

https://community.tp-link.com/en/business/forum/topic/663452

[mbentley]

Sorry this will take a little bit more time - they have once again introduced more inconsistency in the build process so the tarball they have provided looks different than the last beta 🙄. They obviously have zero automation for their builds.

This time we have a zipped tar.gz in a subdirectory (the subdirectory part is new). Last time was just a tar.gz.

[mbentley]

I created https://github.com/mbentley/docker-omada-controller/pull/429 to handle the beta install. I will get that merged and hopefully it will build successfully. I just hate changing the install.sh because it causes all of the images to be re-built due to the changes.

[mbentley]

As reported in #430, it also has a similar issue that I can't reproduce.

[mbentley]

@eblieb - could you provide the full logs from the beginning of the startup of the container so I can try to submit an issue on the TP-Link forums to see if they can provide an idea of why this is happening? I can't imagine it is a problem with the packaging as a container because it should be consistent.

*edit: I have them myself: error_logs

[mbentley]

Well, strange thing just happened - I was able to reproduce the issue while I was testing running the app with OpenJDK 8. I was curious if it was something related to the OpenJDK version but I've been able to reproduce it 3x in a row on fresh installs just doing a basic docker run. I can take the image that I built (mbentley/omada-controller:beta-5.14.20.9-openjdk8-amd64), push it to Docker Hub, run it on another machine that is using the same OS, same kernel, same Docker version just fine though.

[mbentley]

Posted to the forums: https://community.tp-link.com/en/business/forum/topic/670026

[PappyChappy1]

Is there anyway to reinstall the image for 5.14.0.11? That one worked for me, so my backups are for that version...I can't downgrade due to the version #s. And I can't upgrade to 5.14.20.9 because I'm having the startup issues. I guess this is the cost of using beta software, but I really don't want to lose my backup configs!

[mbentley]

I need to update the build process to also tag the beta images with version numbers besides just with the beta tag but for now, here are the last image digests that you can specify:

amd64: mbentley/omada-controller:beta-amd64@sha256:b2cbc1e119581c86f7a31c62f2b854e808b576e54f565d364bfa8439767691d7

arm64: mbentley/omada-controller:beta-arm64@sha256:508258ef9a7616b94afce7aeec04bb66a28f7c201802f0ac43694adcd9753762

armv7l: mbentley/omada-controller:beta-armv7l@sha256:83023cb66332231ae315d327b1426ba2078d6198b2ee2d4898d7cea7b789ffdb

[mbentley]

For beta-5.14.20.9 and further releases, there will be additional tags with the version number. For example, https://hub.docker.com/r/mbentley/omada-controller/tags?page=&page_size=&ordering=&name=beta-5.14.20.9

[PappyChappy1]

Thank you! This allowed me to reinstall 5.14.0.11, at least I'm in good shape until the next version gets fixed

[eblieb]

Any update? Tried installing again and still got the same error

[IAmKonni]

I retried with the latest beta and now the container starts without any issues ...

[eblieb]

I retried with the latest beta and now the container starts without any issues ...

What installer script did you use?

[IAmKonni]

I just used this image with my older docker-compose.yml: image: mbentley/omada-controller:beta-5.14.20.9 Did not change anything else except 5.13 --> beta-5.14.20.9

[eblieb]

Just tried docker-compose with the same image and getting the same error... strange how hit and miss this is.

[eblieb]

Had anyone tried a native install vs the docker and seen if the beta has the same issues on a native Debian install? May test it later

[mbentley]

The problem is that it seems pretty random. There is a strong possibility that you may get the same odds of it working or not working if you install it directly on a host. It would be interesting to see if it fails to work directly installed on the same hosts it fails on in a container though I suppose.

[ruudkobes]

Thanks for your time and effort @mbentley.

I just tried beta-5.14.20.9 and it started without problem. Not sure what that means, but I'll let it run for a while and see if it is stable for me.

[eblieb]

I probably will build a VM to test it.

[eblieb]

The problem is that it seems pretty random. There is a strong possibility that you may get the same odds of it working or not working if you install it directly on a host. It would be interesting to see if it fails to work directly installed on the same hosts it fails on in a container though I suppose.

Yup installed outside docker and runs fine.

[chriexpe]

Had the 5.14.0.11 running just fine for a couple of months, decided to give a try on 5.14.20.19 and got that "Unsatisfied dependency" error too, but thanks to that image digest from mbentley I was able to go back and get it working.

[J0hnMatrix]

Same issue here, not possible to start 5.14 latest release. Had to downgrade by removing LAST_RAN_OMADA_VER.txt and specify 5.13 as tag.

Everything is back and waiting more investigation.

[sant1ago]

Same issue here - I too had to roll back to 5.13 version

[mbentley]

If everyone who is having this problem could also post on the TP-Link Forums in this thread, that would be greatly appreciated. The more noise this gets, the better.

[mbentley]

I've also submitted a support request through their support site hoping that it gets more visibility. Will update if I hear anything.

[alphamike77]

Same issue here, not possible to start 5.14 latest release. Had to downgrade by removing LAST_RAN_OMADA_VER.txt and specify 5.13 as tag.

Everything is back and waiting more investigation.

Trying to rollback now. Where is the LAST_RAN_OMADA_VER.txt located?

Thanks!

[mbentley]

It's in wherever you have mapped /opt/tplink/EAPController/data from inside the container to outside of it.

[alphamike77]

Got it, thanks!

[rmcfadzean]

I was previously on 15.3.22/latest-chromium/fbc3d14b25453727c17be1adaa1bcf691dc0d152204e4498120102052d10f42a and tried to upgrade to the current latest-chromium but encountered the same issue as above. After changing the image to beta-5.14.20.9-chromium and removing the LAST_RAN_OMADA_VER.txt, it works without issue. I haven't tried 5.14.26.1 though.

[hbsagen]

I had the same problem with 5.14 when I updated today. Had to remove the LAST_RAN_OMADA_VER.txt and run 5.13.

[mschingel]

I had the same problem with 5.14 when I updated today. Had to remove the LAST_RAN_OMADA_VER.txt and run 5.13.

How do I do that, I think im having this same issue.

[hbsagen]

I had the same problem with 5.14 when I updated today. Had to remove the LAST_RAN_OMADA_VER.txt and run 5.13.

How do I do that, I think im having this same issue.

1. Find the ID if the omada container sudo docker ps

2. Stop the omada container sudo docker stop -t 60 "ID of omada container without quotes"

3. Remove the omada container sudo docker rm "ID of omada container without quotes"

4. enter sudo mode sudo su

5. goto data folder cd /var/lib/docker/volumes/docker-data (or something like that, do it folder by folder if necessary)

6. remove file rm LAST_RAN_OMADA_VER.txt

[mschingel]

Thanks, I figured it out too. I use Portainor so I stopped the container there. Then "sudo su -" and "rm /opt/tplink/EAPController/data/LAST_RAN_OMADA_VER.txt" Then updated the tag in the stack to image: mbentley/omada-controller:5.13.30.8 I replaced the latest with 5.13.30.8

[helio4k]

I can confirm as the rest of people above downgrade to 5.13 is necessary after updating 5.14.

[evgaqa]

Same for me To revert with portainer just recreate container with 5.13 and remove LAST_RAN_OMADA_VER.txt from /var/lib/docker/volumes/ Omada starts automatically

[KingOperator]

I've the same issue after upgrading to 5.14

[javito1081]

well my post https://github.com/mbentley/docker-omada-controller/issues/442 has been closed cause aparently its the same as this one, has there been any development on fixing this issue?

[CalvinSchwartz]

Using Watchtower it auto updated for me. Could you remove the 5.14 tag from docker hub, set it to testing or something equivalent as cleary 5.14 isn't ready to use?