mbentley

Force refresh the page with your browser - there might have been a change to something in the application that is cached for you. I use Firefox and it works fine here.

Yes, that is one of the upgrade options listed in the upgrade guide.

You'll need to follow the MongoDB upgrade guide: https://github.com/mbentley/docker-omada-controller/tree/master/mongodb_upgrade. The basic process is stop your existing v5 controller, run the upgrade container, update to the v6 image.

Ah crap - what we are seeing right now is a bug in buildkit: https://github.com/moby/buildkit/issues/6217 There are different configs being generated due to an issue related to the created_by field of the EXPOSE line which is actually causing the configs to be different so they ARE different. I'll see if I can work around this... *edit: I've been able to revert back to buildkit 0.23.2 for now which solves the issue

The pipelines do run every morning whether there are changes or not. I'm building about 300 images and a number of them have dependencies that may change over time without there actually being changes that directly trigger a rebuild so that's why they get triggered daily. What happens is that I use buildkit's caching mechanism so if nothing has actually changed, it is able to detect this and nothing actually changes to the underlying image layers. The digests stay the same but the multi-arch manifests are rewritten because the logic to see if an image digest has changed is a huge pain in the ass to capture before hand and then after to determine if I need to have it re-create a manifest and rewriting a manifest should be a harmless thing, especially if the underlying image digests do not change. It sounds like however Unraid is detecting new versions, it's doing so in a weird way. It should be using the actual image digests to see if there is a change and triggering off of that but it must be seeing that something in the manifest itself is different. Any idea if there is some sort of 3rd party tool, like watchtower, that's embedded in Unraid that's doing this detection? I don't have anything that Unraid and I am not familiar with what it is doing exactly but I do know that this has come up before - which is why I can easily recall what is going on. *edit: never mind, it is watchtower. Here is what is going on: Watchtower compares the manifest digest (the SHA256 hash of the manifest JSON) rather than just the underlying layer digests. When a registry rewrites a manifest - even without changing any actual image layers - the manifest gets a new digest because: Timestamps in the manifest may change (this is the trigger in this case) Registry metadata gets updated The manifest JSON structure might be reformatted Multi-architecture manifests can be rebuilt (this is also happening here) I have no idea if it is possible to have Unraid switch out the tool being used but something like https://github.com/crazy-max/diun might be a good alternative because I believe it actually detects proper changes in the manifests.

I have build pipelines and security vulnerability scanning that can trigger rebuilds of images. Unlike what most people do where they build an image tag once and never update it, I continually make updates to supported tags. If there have been changes to anything that would cause the build cache to be invalidated, the image would be updated and pushed. If there are fixable vulnerabilities in the underlying base image, it will force a rebuild as well so it’s not version bumps but changes and security patches.

If you move from v5 to v6, you will need to perform the database upgrade because starting with the v6 images, I've upgraded the base OS and that includes installing MongoDB from the upstream MongoDB package repositories. The previous version was using 3.6.8 which is way out of support at this point. If you try to run the v6 beta version, the entrypoint will detect that you didn't upgrade MongoDB and it will fail to start the controller.

One thing I might suggest for the template is to update the docker image that is used to include a tag. I just recently added a major version tag so you can specify mbentley/omada-controller:5 With 6.x coming out soon, at least there is a beta version of 6.x, there will be a manual upgrade step that is needed to bring the base OS image and the MongoDB up to a modern version. I am not going to move latest away from the 5.x branch though because I intend on letting the latest tag die eventually and I do not want to cause everyone's deployment to break if it auto-updates.

See https://github.com/mbentley/docker-omada-controller/issues/418#issuecomment-2223732459 for how to resolve the issue - it's basically removing a version check file which prevents you from running an older version of the software on accident. In this case, it is safe to roll back to 5.13 because 5.14 never started successfully (unless you were running a beta version and you would know if you were).

This is an issue with the TP-Link software. See https://github.com/mbentley/docker-omada-controller/issues/418#issuecomment-2223732459 for how to resolve the issue - it's basically removing a version check file which prevents you from running an older version of the software on accident. In this case, it is safe to roll back to 5.13 because 5.14 never started successfully (unless you were running a beta version and you would know if you were).

If you want to run the beta version, I have a few specific tags depending on if you want to use the `latest` equivalent for beta (the `beta` tag), or `beta-5.14` for whatever the latest beta 5.14.x version is and there is also a `beta-5.14.20.9` tag if you want the explicit version.

Get container logs using: docker logs omada-controller >& output.log And mongodb logs using: docker cp omada-controller:/opt/tplink/EAPController/logs/mongod.log mongod.log Replace the container name if it is not omada-controller.

Sorry, I missed the notification on this. Based on these volume paths, you did not specify a volume name. You can either use Docker managed volumes where you provide the persistent data path a name or you can use a bind mount. The image is configured to automatically create a volume but if you do not specify a name, it will create one with a random guid. In this case, your data is in the volume `a13fa10908be8af6443af13b1d41a1a8ffa0fbd1f9fa8e98224ae985e83e679d` and your logs are in `9038ba554ee7b24e19c77106f41be5313d61031dff1c5d6ba64e149a24dc1a3f` for this instance of your controller. You probably have other volumes that show with `docker volume ls` but you won't be able to tell what is what without manually inspecting the contents in `/var/lib/docker/volumes/<volume_guid>/_data`.

Sorry, I was assuming you understood that `omada-controller` was the name of your controller and you only paste this part: docker inspect --format '{{json .Mounts}}' <controller-name>

If you don't know where the container is mounted the data, you can use docker inspect to find out: This just lists the mounts: # docker inspect omada-controller | jq '.[]|.Mounts' [ { "Type": "bind", "Source": "/zfs/apps/omada-controller/cert", "Destination": "/cert", "Mode": "", "RW": false, "Propagation": "rprivate" }, { "Type": "bind", "Source": "/zfs/apps/omada-controller/data", "Destination": "/opt/tplink/EAPController/data", "Mode": "", "RW": true, "Propagation": "rprivate" }, { "Type": "bind", "Source": "/zfs/apps/omada-controller/logs", "Destination": "/opt/tplink/EAPController/logs", "Mode": "", "RW": true, "Propagation": "rprivate" } ] Or if you don't have jq: # docker inspect --format '{{json .Mounts}}' omada-controller [{"Type":"bind","Source":"/zfs/apps/omada-controller/data","Destination":"/opt/tplink/EAPController/data","Mode":"","RW":true,"Propagation":"rprivate"},{"Type":"bind","Source":"/zfs/apps/omada-controller/logs","Destination":"/opt/tplink/EAPController/logs","Mode":"","RW":true,"Propagation":"rprivate"},{"Type":"bind","Source":"/zfs/apps/omada-controller/cert","Destination":"/cert","Mode":"","RW":false,"Propagation":"rprivate"}]