Open IAmKonni opened 5 months ago
javito1081
commented
2 months ago 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?
well i have another instance on a diferent server on which i updated and is working without issues, but this one is not :-(
mbentley
commented
2 months ago 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?
WARNING: Before you do anything, make sure to take a backup of your persistent data in case of an issue when performing the steps below!
No, unfortunately TP-Link has not responded. Assuming 5.14 has NEVER successfully started on your system, you can clear the version check file (LAST_RAN_OMADA_VER.txt in the persistent data directory from /opt/tplink/EAPController/data inside the container) and roll back to 5.13 by specifying 5.13 as the tag.
For example, if your container is named omada-controller, you can get the location of where the data is mounted, no matter if it is a bind mount or a volume:
docker inspect -f '{{ range .Mounts }}{{ if eq .Destination "/opt/tplink/EAPController/data" }}{{ .Source }}{{ end }}{{ end }}' omada-controllerVolume example:
$ docker inspect -f '{{ range .Mounts }}{{ if eq .Destination "/opt/tplink/EAPController/data" }}{{ .Source }}{{ end }}{{ end }}' omada-test
/var/lib/docker/volumes/dbd53e89af74c1340784249f2961a6d549dfbe3af4e47b31d182b68d521132ff/_data
# combine that to show the directory contents
$ sudo ls -l $(docker inspect -f '{{ range .Mounts }}{{ if eq .Destination "/opt/tplink/EAPController/data" }}{{ .Source }}{{ end }}{{ end }}' omada-test)
[sudo] password for mbentley:
total 84
drwxr-xr-x 4 508 508 69632 Jul 11 16:06 db
drwxr-xr-x 2 508 508 4096 Jul 11 15:43 html
drwxr-xr-x 2 508 508 4096 Jul 11 15:43 keystore
-rw-r--r-- 1 root root 10 Jul 11 15:43 LAST_RAN_OMADA_VER.txt
drwxr-xr-x 2 508 508 4096 Jul 10 06:51 pdfBind mount example:
$ docker inspect -f '{{ range .Mounts }}{{ if eq .Destination "/opt/tplink/EAPController/data" }}{{ .Source }}{{ end }}{{ end }}' omada-controller
/data/omada-controller/data
# combine that to show the directory contents
$ sudo ls -l $(docker inspect -f '{{ range .Mounts }}{{ if eq .Destination "/opt/tplink/EAPController/data" }}{{ .Source }}{{ end }}{{ end }}' omada-controller)
[sudo] password for mbentley:
total 176
drwxr-xr-x 2 omada omada 4096 Jul 11 01:15 autobackup/
drwxr-xr-x 4 omada omada 151552 Jul 11 16:07 db/
drwxr-xr-x 3 omada omada 4096 Jun 30 2023 device-firmware/
drwxr-xr-x 2 omada omada 4096 Jul 11 2022 html/
drwxr-xr-x 2 omada omada 4096 Jul 10 07:25 keystore/
-rw-r--r-- 1 root root 10 Jul 10 07:25 LAST_RAN_OMADA_VER.txt
drwxr-xr-x 2 omada omada 4096 Jul 11 2022 pdf/Remove the LAST_RAN_OMADA_VER.txt file and then start the container again and you should be back up and running.
mbentley
commented
2 months ago 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?
Trying to provide TP-Link as much info as possible on the forums - I have an example where I have 6 systems, all unique, and 5 of the 6 work fine running the image but it's like it's always this one that doesn't work. If I removed the image, or rolled back to 5.13 being latest it would be problematic for those who have successfully been able to run 5.14 as it would then break their controllers.
And honestly, this is a lesson in never running the latest tag. I have seriously considered actually deleting it from the repo because blindly upgrading isn't a great idea. I don't even run latest for my own personal controller 😆 I always run the major.minor tag (like 5.14).
javito1081
commented
2 months ago 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?
No, unfortunately TP-Link has not responded. Assuming 5.14 has never successfully started on your system, you can clear the version check file (
LAST_RAN_OMADA_VER.txtin the persistent data directory from/opt/tplink/EAPController/datainside the container) and roll back to 5.13 by specifying 5.13 as the tag.For example, if your container is named
omada-controller, you can get the location of where the data is mounted, no matter if it is a bind mount or a volume:docker inspect -f '{{ range .Mounts }}{{ if eq .Destination "/opt/tplink/EAPController/data" }}{{ .Source }}{{ end }}{{ end }}' omada-controllerVolume example:
$ docker inspect -f '{{ range .Mounts }}{{ if eq .Destination "/opt/tplink/EAPController/data" }}{{ .Source }}{{ end }}{{ end }}' omada-test /var/lib/docker/volumes/dbd53e89af74c1340784249f2961a6d549dfbe3af4e47b31d182b68d521132ff/_data # combine that to show the directory contents $ sudo ls -l $(docker inspect -f '{{ range .Mounts }}{{ if eq .Destination "/opt/tplink/EAPController/data" }}{{ .Source }}{{ end }}{{ end }}' omada-test) [sudo] password for mbentley: total 84 drwxr-xr-x 4 508 508 69632 Jul 11 16:06 db drwxr-xr-x 2 508 508 4096 Jul 11 15:43 html drwxr-xr-x 2 508 508 4096 Jul 11 15:43 keystore -rw-r--r-- 1 root root 10 Jul 11 15:43 LAST_RAN_OMADA_VER.txt drwxr-xr-x 2 508 508 4096 Jul 10 06:51 pdfBind mount example:
$ docker inspect -f '{{ range .Mounts }}{{ if eq .Destination "/opt/tplink/EAPController/data" }}{{ .Source }}{{ end }}{{ end }}' omada-controller /data/omada-controller/data # combine that to show the directory contents $ sudo ls -l $(docker inspect -f '{{ range .Mounts }}{{ if eq .Destination "/opt/tplink/EAPController/data" }}{{ .Source }}{{ end }}{{ end }}' omada-controller) [sudo] password for mbentley: total 176 drwxr-xr-x 2 omada omada 4096 Jul 11 01:15 autobackup/ drwxr-xr-x 4 omada omada 151552 Jul 11 16:07 db/ drwxr-xr-x 3 omada omada 4096 Jun 30 2023 device-firmware/ drwxr-xr-x 2 omada omada 4096 Jul 11 2022 html/ drwxr-xr-x 2 omada omada 4096 Jul 10 07:25 keystore/ -rw-r--r-- 1 root root 10 Jul 10 07:25 LAST_RAN_OMADA_VER.txt drwxr-xr-x 2 omada omada 4096 Jul 11 2022 pdf/
Ya i did that before posting, my controller is back to runing on 5.13, but i cant run it on 5.14, no mattar if its a fresh install or not :-(
surfek
commented
2 months ago The same issue here... Had to revert to 5.13. Will post on TP-Link forum
lucianor
commented
2 months ago @mbentley did you try different versions of the base image or combinations of openjdk / mongo versions ? I know the latter can be challenging because it will need a DB upgrade, but I'm rebuilding this image myself and trying different combinations to see if I can make it work.. wondering if you are doing the same and if we can divide and conquer
mbentley
commented
2 months ago @mbentley did you try different versions of the base image or combinations of openjdk / mongo versions ? I know the latter can be challenging because it will need a DB upgrade, but I'm rebuilding this image myself and trying different combinations to see if I can make it work.. wondering if you are doing the same and if we can divide and conquer
No, my testing has been focused on running the exact same image on multiple machines. In my case, it successfully runs on 5 of the 6 I tried it on. I am not a Java/Spring Boot expert but it just seems to be a problem with how they define the dependencies and they've created a circular dependency but I have no idea why that would show up randomly for different users, especially considering I am testing this on multiple machines, a few that are clones of each other. The one where it fails to run is a clone of another where I have just about the exact same packages installed and they're the same OS, kernel, etc.
One thing that would be simple for running different MongoDB versions would be to use an externally hosted MongoDB. You can just run the existing 5.14 image but just use two required env vars: of MONGO_EXTERNAL and EAP_MONGOD_URI. I can test that on my one VM that is not working.
mbentley
commented
2 months ago I just tested MongoDB 3, 4, and 7 on my VM where it always happens - same behavior every time using the current mbentley/omada-controller:5.14@sha256:ce429a64b11bcc8f86fdc5aa1990a54a158de8ce83f92c316bb556f29f732afd image.
*edit: I am currently building an image with OpenJDK 8 instead of 17 to also test again although it didn't help with the beta version. Will do that test against my same 6 systems. It's mbentley/omada-controller:5.14-rebuildv2-amd64 if you want to test it with anything.
*edit2: Same issue on the same 1 of the 6 machines with the OpenJDK 8 version.
antbarney
commented
2 months ago Also running into this issue, as a Note I can successfully run "beta-5.14.20.9-chromium" but any of the other 5.14 images fail to start for me. I have reverted to 5.13 and seem to be back up tho.
mbentley
commented
2 months ago Also running into this issue, as a Note I can successfully run "beta-5.14.20.9-chromium" but any of the other 5.14 images fail to start for me. I have reverted to 5.13 and seem to be back up tho.
Interesting data point - beta-5.14.20.9-chromium runs fine on my VM that has issues. The beta-5.14.20.9 tag also runs fine although that makes sense seeing as beta-5.14.20.9-chromium just extends the beta-5.14.20.9 image by adding the chromium package.
I also tested mbentley/omada-controller:beta-5.14.0.11-rebuild which I just built, which is just a rebuild of the exact same previously released beta-5.14.0.11 and that works fine as well on my troublesome machine.
lucianor
commented
2 months ago thanks for confirming. My tests have confirmed the same - OpenJDK and MongoDB does not make a difference - under an arm64 (Orange Pi 5).
dougle03
commented
2 months ago What's the solution to get the controller back up? FYI Running in Docker on a Pi4. Thanks
surfek
commented
2 months ago What's the solution to get the controller back up? FYI Running in Docker on a Pi4. Thanks
get back to 5.13 version and remove LAST_RAN_OMADA_VER.txt file. After that it shall start with 5.13....
dougle03
commented
2 months ago Hi, tried that, no dice. Now getting exec /entrypoint.sh: exec format error over and over...
w1zz4
commented
2 months ago Hi, tried that, no dice. Now getting exec /entrypoint.sh: exec format error over and over...
It works, you either did it wrong or you have a different issue not related to this one. There was no change made to controller DB as it doesn’t even reach staring DB before failure. so going back is only a matter a changing image to force 5.13 and deleting LAST_RAN_OMADA_VER.txt
dougle03
commented
2 months ago So I've deleted the txt file and rolled back to mbentley/omada-controller:5.12-amd64 And still getting the same exec /entrypoint.sh: exec format error
dougle03
commented
2 months ago Just tried mbentley/omada-controller:5.14-rebuildv3-amd64 and still the same. Pretty sure I've just completely blown my installation. What can I clear out of the mapped volume to restore things... ?
dougle03
commented
2 months ago Think it's time to restore my volume from the nightly backup... Grrr.... Also time to disable Watchtower...
w1zz4
commented
2 months ago Maybe post full error (formatted) so we will be able to help you. But I we said, this error is not related to your issue.
wait are you trying to run amd64 image on a raspberry pi? I don’t think it’s possible…
mbentley
commented
2 months ago exec format error tends to be related to attempting to run the wrong architecture of image.
DO NOT TRY TO RUN 5.12 IF YOU ALREADY WERE RUNNING 5.13! You will have to restore from backup if you do as it will 100% screw up the persistent data. That's why the version check was added - to prevent just that.
Just pull the mbentley/omada-controller:5.13 image and run that. It will pull the correct architecture as it is a multi-arch image.
The rebuild images were just for testing purposes, nothing that I would ever intend anyone to run in a production setup.
w1zz4
commented
2 months ago Yeah pretty sure it’s an arch issue…
try using mbentley/omada-controller:5.13.30.8-arm64
dougle03
commented
2 months ago DO NOT TRY TO RUN 5.12 IF YOU ALREADY WERE RUNNING 5.13!
Oops, too late - Time to hit Active backup - how long ago should I roll back to...?
dougle03
commented
2 months ago Just pull the
mbentley/omada-controller:5.13image and run that. Working now on the above version. Thanks all. Pete
sbackx
commented
2 months ago Thank you to everyone for saving my controller with the downgrade instructions.
Count me as another failed upgrade.
Kingslayer9988
commented
2 months ago Another failed Upgrade - Non of the 5.14 tags run
Subzeero
commented
2 months ago Noting that my upgrade from 5.13 to 5.14 was successful on first attempt. Running on a 4GB Raspberry Pi 4. I can provide logs or other info if it helps.
hjongedijk
commented
2 months ago 5.14 not running on Raspberry Pi 4 Model B 8GB after upgrade from 5.13
mooglestiltzkin
commented
2 months ago @mbentley
I also experience issue with 5.14
rolling back to 5.13 worked
i use truenas to install jailmaker to then install docker. Then i deploy mbently omada controller docker container using dockge docker compose.
schrackin
commented
1 month ago Hi Folks,
I've been using Mbentley's Omada controller images for years now without any issues. Up until the weekend when I updated the image on my Synology DS415+ NAS. As far as I can remember, I had been using version 5.13, then I tried to update to the latest image which contains the 5.14 controller software.
I did the update process as usual. In the Synology Docker app, I downloaded the mbentley/omada image with the latest tag, copied the container, then reset the new Docker container. However, the new Docker container can't start properly. I've attached the Docker container logs for further analysis. Could you please tell me, what would be the solution for the startup problem? omada-controller-copy.csv
J0hnMatrix
commented
1 month ago Hello, Try to repeat the operation but not with the "latest" tag but with the "5.13", with the same volume (backup it before) and the Omada Controller should start again.
schrackin
commented
1 month ago Hello, Try to repeat the operation but not with the "latest" tag but with the "5.13", with the same volume (backup it before) and the Omada Controller should start again.
Thanks for the tip, what can i do, if i don't have a backup from the previous version? (I will setup a backup job after i've fixed the current problem :) )
mbentley
commented
1 month ago Hello, Try to repeat the operation but not with the "latest" tag but with the "5.13", with the same volume (backup it before) and the Omada Controller should start again.
Thanks for the tip, what can i do, if i don't have a backup from the previous version? (I will setup a backup job after i've fixed the current problem :) )
In this case, you do not need a backup because the controller never successfully started 5.14 so no database migrations occurred. Follow these instructions to clear the version check file that will prevent it from starting.
...and once you get your controller back up and running, configure the automatic backups!
J0hnMatrix
commented
1 month ago Hello, Try to repeat the operation but not with the "latest" tag but with the "5.13", with the same volume (backup it before) and the Omada Controller should start again.
Thanks for the tip, what can i do, if i don't have a backup from the previous version? (I will setup a backup job after i've fixed the current problem :) )
Not a problem if you don't have a backup, but you should take one before doing the "downgrade" Also, don't forget to rename/delete the "LAST_RAN_OMADA_VER.txt" file inside the persistent volume before starting the Omada 5.13
schrackin
commented
1 month ago Hello, Try to repeat the operation but not with the "latest" tag but with the "5.13", with the same volume (backup it before) and the Omada Controller should start again.
Thanks for the tip, what can i do, if i don't have a backup from the previous version? (I will setup a backup job after i've fixed the current problem :) )
Not a problem if you don't have a backup, but you should take one before doing the "downgrade" Also, don't forget to rename/delete the "LAST_RAN_OMADA_VER.txt" file inside the persistent volume before starting the Omada 5.13
Thanks for your fast responses. I managed to fix the issue based on your posts. The v5.13 container is running now, and my home network is rocking again
lucianor
commented
1 month ago @mbentley since you asked, I tried running 5.14.26.1 directly on the Docker host server: Ubuntu 24.04, arm64, kernel 6.1.0-1020-rockchip, openjdk 17.0.11, mongo db version v7.0.12.
I installed the .tar.gz version without any modifications, just had my DB upgraded to v7.0 and tried with a blank DB. And I was able to run it on the server without any errors reported. Although my bare metal config is different from the base image, I thought this was worth nothing.
mbentley
commented
1 month ago Just an update: I sent a direct message to Hank21 on the TP-Link Community forum this morning to see if doing so would bring some attention to this issue as I can see just from this GitHub issue, there are 30 people who have posted with issues and there are now a total of 25 posts in that thread. I have also not received any updates from TP-Link support since I submitted a support case 7 days ago.
mooglestiltzkin
commented
1 month ago yeah, just recently bought spanky new eap-773. was hoping for a good experience, but to my shock now stuck on an older 5.13 because of this issue. hopefully tplink supports us on this :(
sbackx
commented
1 month ago @mbentley is there any way that we can help put extra pressure on TP-Link on your behalf? I just posted on the thread mentioned in the first post but let me know if there is anything else I can do.
mbentley
commented
1 month ago @mbentley is there any way that we can help put extra pressure on TP-Link on your behalf? I just posted on the thread mentioned in the first post but let me know if there is anything else I can do.
The only thing I can really think of is the more people who make noise on the forums, the better. Besides that, support tickets but the fact that I haven't gotten a response in 7 days tells me they are probably dealing with actual business customers with support contracts which I certainly do not have. My only TP-Link contacts are their forum moderators and I don't have any strong relationships there.
mbentley
commented
1 month ago @ksoviero noticed something slightly different in the logs the first time it failed to start in #445 but then he ended up with the same messages as everyone else:
INFO: Validating user/group (omada:omada) exists with correct UID/GID (508:508)
INFO: Group (omada) doesn't exist; creating
INFO: User (omada) doesn't exist; creating
INFO: Time zone set to 'America/Chicago'
INFO: Value of 'manage.http.port' already set to 8088 in omada.properties
INFO: Value of 'manage.https.port' already set to 8043 in omada.properties
INFO: Value of 'portal.http.port' already set to 8088 in omada.properties
INFO: Value of 'portal.https.port' already set to 8843 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
WARN: Ownership not set correctly on '/opt/tplink/EAPController/properties'; setting correct ownership (omada:omada)
INFO: Version check passed; image version (5.14.26.1) >= the last version ran (5.13.30.8); writing image version to last ran file...
INFO: userland/kernel check passed
INFO: Starting Omada Controller as user omada
07-17-2024 02:24:43.217 INFO [main] [] c.t.s.o.s.OmadaBootstrap(): record: bootstrap prepare
07-17-2024 02:24:43.240 INFO [main] [] c.t.s.o.s.e.c(): Configuration omadacType is linux
07-17-2024 02:24:43.185 INFO [main] [] c.t.s.o.s.OmadaLinuxMain(): record: start the omada controller
07-17-2024 02:24:43.189 INFO [main] [] c.t.s.o.s.OmadaLinuxMain(): record: set property finished
07-17-2024 02:24:43.214 INFO [main] [] c.t.s.o.s.OmadaLinuxMain(): record: configure log finished
07-17-2024 02:24:43.239 INFO [main] [] c.t.s.o.c.o.a.b(): success to load configuration omada.properties
07-17-2024 02:24:43.240 INFO [main] [] c.t.s.o.c.o.OmadacType(): omadacType: Local Controller
07-17-2024 02:24:43.313 INFO [main] [] c.t.s.o.s.OmadaBootstrap(): going to start local mongod.
07-17-2024 02:25:03.023 INFO [main] [] c.t.s.o.s.t.SpringBootStartUpTask(): record: task SpringBootStartupTask start
07-17-2024 02:25:02.393 INFO [main] [] c.t.s.o.s.s.b(): mongodb process id is 209
07-17-2024 02:25:02.975 INFO [main] [] c.t.s.o.s.OmadaBootstrap(): record: bootstrap record finished
07-17-2024 02:25:03.023 INFO [main] [] c.t.s.o.s.OmadaBootstrap(): record: start run omada tasks
07-17-2024 02:25:02.395 ERROR [main] [] c.t.s.f.c.FacadeUtils(): facadeMsgEnable is not enable, msg: Mongo DB server started
07-17-2024 02:25:02.395 INFO [main] [] c.t.s.o.s.s.b(): Mongo DB server started
07-17-2024 02:25:02.976 INFO [main] [] c.t.s.o.s.OmadaBootstrap(): record: bootstrap startup
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
/\\ / ___'_ __ _ _(_)_ __ __ _ \ \ \ \
=========|_|==============|___/=/_/_/_/
. ____ _ __ _ _
\\/ ___)| |_)| | | | | || (_| | ) ) ) )
' |____| .__|_| |_|_| |_\__, | / / / /
:: Spring Boot :: (v2.7.18)
07-17-2024 02:25:03.587 INFO [main] [] c.t.s.o.s.OmadaLinuxMain(): Starting OmadaLinuxMain v5.14.26.1 using Java 17.0.11 on omada-0 with PID 1 (/opt/tplink/EAPController/lib/local-starter-5.14.26.1.jar started by omada in /opt/tplink/EAPController/lib)
07-17-2024 02:25:03.589 INFO [main] [] c.t.s.o.s.OmadaLinuxMain(): No active profile set, falling back to 1 default profile: "default"
at com.tplink.smb.omada.starter.OmadaBootstrap.b(SourceFile:201) ~[local-starter-5.14.26.1.jar:5.14.26.1]
at com.tplink.smb.omada.starter.OmadaLinuxMain.b(SourceFile:87) ~[local-starter-5.14.26.1.jar:5.14.26.1]
Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'commThreadPool' available
at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeanDefinition(DefaultListableBeanFactory.java:874) ~[spring-beans-5.3.31.jar:5.3.31]
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:208) ~[spring-beans-5.3.31.jar:5.3.31]
07-17-2024 02:25:09.550 INFO [Thread-0] [] c.t.s.o.s.s.b(): Going to stop mongod which pid is 209
at com.tplink.smb.omada.common.concurrent.thread.a.a(SourceFile:243) ~[omada-common-5.14.26.1.jar:5.14.26.1]
at java.lang.Thread.run(Thread.java:840) [?:?]
at org.springframework.beans.factory.support.AbstractBeanFactory.getMergedLocalBeanDefinition(AbstractBeanFactory.java:1358) ~[spring-beans-5.3.31.jar:5.3.31]
... 4 more
java.lang.ExceptionInInitializerError: null
07-17-2024 02:25:09.547 INFO [Thread-0] [] c.t.s.o.s.OmadaBootstrap(): Failed to shutdown customThread.
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:309) ~[spring-beans-5.3.31.jar:5.3.31]
at org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:1168) ~[spring-context-5.3.31.jar:5.3.31]
at com.tplink.smb.omada.common.spring.a.a(SourceFile:28) ~[omada-common-5.14.26.1.jar:5.14.26.1]
at com.tplink.smb.omada.common.concurrent.thread.a$a.<clinit>(SourceFile:55) ~[omada-common-5.14.26.1.jar:5.14.26.1]
07-17-2024 02:25:12.585 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
07-17-2024 02:25:16.601 INFO [Thread-0] [] c.t.s.o.s.OmadaBootstrap(): success to shutdown mongodb database
07-17-2024 02:25:16.601 INFO [Thread-0] [] c.t.s.o.s.OmadaBootstrap(): Omada Controller exited
07-17-2024 02:25:16.601 INFO [Thread-0] [] c.t.s.o.s.OmadaLinuxMain(): ShutdownHook: service stopped.
HiveLeader
commented
1 month ago Same problem here!
fanto237
commented
1 month ago I am also facing the same issue, going back to previous version (5.13) didn't change anything, although it worked before I updated to 5.14
mooglestiltzkin
commented
1 month ago I am also facing the same issue, going back to previous version (5.13) didn't change anything, although it worked before I updated to 5.14
u mean roll back to 5.13 not working as well?
What i did was, DELETE the tplink docker persistent data. Then did a clean install for 5.13
It loaded up fine. Then i import my omada backup config. Done. Now it's working like before.
mbentley
commented
1 month ago Well, the good news is that Fae acknowledged @mooglestiltzkin in the thread so at least there is some recent visibility by someone from TP-Link.
mbentley
commented
1 month ago Well good timing I guess as I just heard back from support.
Our dedicated engineers have conducted extensive testing but have not been able to replicate the issue in our lab, and our R&D team has yet to provide further analysis results. Based on the error information provided, it seems to be a dependency-related problem. To address this, we have implemented significant optimizations in the upcoming 5.14.30 version. We encourage you to stay updated on our website and try downloading the 5.14.30 version to test if the issue persists.
I've mentioned in a reply that I would be happy to test any pre-release version of code they could provide so hopefully they take me up on that. I'll be keeping an eye out for a new beta version as well.
fanto237
commented
1 month ago I am also facing the same issue, going back to previous version (5.13) didn't change anything, although it worked before I updated to 5.14
u mean roll back to 5.13 not working as well?
Yes, I meant rolling back to 5.13 didn't actually change anything.
What i did was, DELETE the tplink docker persistent data. Then did a clean install for 5.13
It loaded up fine. Then i import my omada backup config. Done. Now it's working like before. I didn't back up my config performing the upgrade so, I can't delete the Omaha volume otherwise I will lose everything :(
dougle03
commented
1 month ago I didn't back up my config performing the upgrade so, I can't delete the Omaha volume otherwise I will lose everything :(
Omada automatically creates a backup, it's stored in the 'data' persistent volume /data/autobackup - Unless you changed settings, you should see 7 backups with various dates.
mbentley
commented
1 month ago Yes, I meant rolling back to 5.13 didn't actually change anything.
What do you mean by this? Do you mean that it will not start when you rolled back to 5.13? Did you remove the version file to bypass the version check? Exact error messages from the logs and the exact steps you took will help here.
mooglestiltzkin
commented
1 month ago mbentley is right
if you roll back after having attempted to go 5.14 but it didn't work out, then you have to do the procedure mbentley said to do.
for me i did it a bit different. i just stop/inactive the container, then deleted the omada folder, then redeploy the docker compose (with the version set to 5.13 of course).
It deploys successfully, then i just go web ui, then import config, then it's all back to working condition.
ya i would have volunteered to join the closed beta, but i was never invited :{ US only or something xd
KevinEdry
commented
1 month ago I would also love top see this solved so we can upgrade to the latest version. @mbentley thanks for pointing me in the right direction 💪
🚨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.14never successfully ran for you, you can manually remove the version check file and specify the5.13tag 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-18: TP-Link acknowledged the issue - see this comment in this thread or directly to this TP-Link forum post
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.7for 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 -dHow You're Launching the Container
Container Logs
MongoDB Logs
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.