[Bug]: 64b problems
#410
-
Controller Version5.13.23 Describe the BugController fails to start (Known bug) Expected BehaviorController starts Steps to Reproduce
How You're Launching the ContainerContainer LogsMongoDB LogsAdditional ContextI have followed the instruction from https://github.com/mbentley/docker-omada-controller/blob/master/KNOWN_ISSUES.md#mismatched-userland-and-kernel |
Beta Was this translation helpful? Give feedback.
Answered by
mbentley
Feb 28, 2024
Replies: 7 comments 7 replies
-
|
Is this a brand new deployment you're trying to do or is this an existing deployment that was previously working? What error returned when you attempt to start the container? If it starts, what shows in the logs? The original issue where this came up is #304 and there is a good bit of log detail of what the behavior is. Just want to confirm that it is indeed what you're seeing as there is no point chasing something that doesn't work. This info from this post would be helpful:
I am not sure why a raspberry pi would fail to boot when reverting to the 32 bit kernel, especially if it was booting it before just fine. |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Hi Matt, thanks for responding. uname -a cat /etc/os-release docker info dpkg --print-architecture for i in /etc/apt/sources.list /etc/apt/sources.list.d/*; do echo "### $i"; cat "$i";echo;done List of current containers, Note Omada shows running but it's stalled with the DB message. |
Beta Was this translation helpful? Give feedback.
1 reply
-
|
OK, interesting. So in your case, you have a 64 bit userland and a 64 bit kernel already. If you had a 32 bit userland, it would not show the output of Side note: I would never use the Have you always been running the The You need to verify if you're seeing this or not. A couple other quick tests you could do - just try to see if these will start the container and output the java version: Should output: Should output: That being said, if you were somehow running the armv7l container previously and it was actually running properly, the issue is going to be that you were running an older MongoDB (2.6.10) and I don't think switching directly from 2.6.10 to 3.6.6 will just work seamlessly - it expects some sort of upgrade/data migration which isn't typically something simple to explain. |
Beta Was this translation helpful? Give feedback.
Answer selected by
mbentley
-
|
Hi Matt, thanks for coming back to me: I've been running armv7L since I setup the Pi nearly two years ago and the controller did run ok (A bit slow at times but all good) I ran And I ran Does that help? I tried running in Portainer the arm64 container |
Beta Was this translation helpful? Give feedback.
1 reply
-
|
Both of the containers ran so it at least isn't some other problem that I hadn't considered so that at least narrows down weird container launching start issues. |
Beta Was this translation helpful? Give feedback.
-
|
Oops, spoke too soon. No clients listed and this is the devices page... |
Beta Was this translation helpful? Give feedback.
2 replies
-
|
I can't tell for sure because I don't have any information about how you're running the container but this looks similar to what I see when you don't have all of the updated ports exposed when you're just using port mapping. I'd ask for all of your ports but it might be easier for me to just point you to all of them: https://github.com/mbentley/docker-omada-controller?tab=readme-ov-file#using-port-mapping Otherwise, get me the output of |
Beta Was this translation helpful? Give feedback.
-
|
Now appears fixed. Now: |
Beta Was this translation helpful? Give feedback.
-
|
The container logs shows: |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
I presume this is the db incompatibilities you mentioned.. |
Beta Was this translation helpful? Give feedback.
3 replies
-
|
That would be easiest checked by looking at the MongoDB logs in one of these ways: or |
Beta Was this translation helpful? Give feedback.
-
|
I think we're fixed now, but here's the 100 lines of logs. Many thanks for your help on this Matt 👍 |
Beta Was this translation helpful? Give feedback.
-
|
Yup, that looks like a happy MongoDB. Glad it’s working! |
Beta Was this translation helpful? Give feedback.
-
Again, thanks so much for your help and patients.. 👌 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
OK, interesting. So in your case, you have a 64 bit userland and a 64 bit kernel already. If you had a 32 bit userland, it would not show the output of
dpkg --print-architectureasarm64. The instances where it was originally a problem, it was where they were originally both 32 bit and then the kernel was switched from 32 bit to 64 bit causing a mixed 32 bit userland with a 64 bit kernel and MongoDB 2.6.10 fails to start under a 64 bit kernel.Side note: I would never use the
latesttag in this instance, always a specific major/minor version:5.13just because I can't control when TP-Link has breaking changes in a new version but I will ensure that there are no breaking changes, unless TP…