MongoDB v4.x Compatibility (Raspberry Pi)
Hello,
MongoDB v3.6.x is pre-compiled for ARM64 (e.g., a Raspberry Pi) only for Ubuntu 16.04. (from the official mongoDB website)
MongoDB v4.4.x is pre-compiled for ARM64 for Ubuntu 18.04, 20.04.
MongoDB is not supported in Debian for ARM64.
Ubuntu is pre-compiled for Raspberry Pi in versions 18.04, 20.04. (no longer 16.04, or I couldn't find it)
--> I can't seem to get MongoDB v3.6.x to work in a currently supported OS (Ubuntu or Debian) on the Raspberry Pi
So I did try to use MongoDB v4.4.x with Ubuntu 18.04 on a Raspberry Pi 3B with Omada v4.2.8. It starts and runs, but typically after a few days I see Omada has stopped running. "tpeap start" doesn't work, but a reboot does. I can't figure out if this reoccurring crash is due to mongoDB v4.4.x or not.
My questions:
- Are we sure mongoDB v4.4.x isn't compatible with the latest Omada? It does seem to run, but I don't yet know why after a few days mine stops running.
- mongoDB v3.6.x is quite old and no longer supported for ARM64 current operating systems. May I request Omada to officially support mongoDB 4.4.x?
- Anyone else have experience to add? If someone knows what I should look for in the log files to determine the crashing of Omada, I would appreciate it.
Thank you in advance!
(a few recent threads ask related questions like this or this)
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
This whole situation is a F&(&(ing joke. TP-Link does not seem to care very much about the software SDN Controller. The reliance on outdated Mongo packages and not officially supporting an Ubuntu LTS version that has been out for nearly a year is absurd. I certainly don't see how they can expect anyone in an enterprise environment to take this seriously.
I've been struggling with Ubuntu 20.04, trying to get mongodb packages and dependencies installed. Suffice it to say, the TP-Link installation process doesn't work. I got SDN up and running once, but had clients that wouldn't connect to my APs being managed, so I rolled back.
I wanted to reply just so your post didn't go unnoticed. Hopefully we can get a fix to this.
- Copy Link
- Report Inappropriate Content
Thanks for your response. I agree that, for a serious enterprise solution, the latest LTS versions of UNIX software should be supported.
The good news is that Omada v4.2.11 ran for 10 days straight for me on Ubuntu 20.04 on a Raspberry Pi 4B (4GB) with MongoDB v4.4.3. (and I had to reboot after 10 days for other reasons, not because Omada crashed) Granted, I may not be using all the advanced features of Omada, but core functionality was OK. I need to add, however, that there are still a number of serious, known bugs in Omada that are currently being worked on that can be very limiting, so I use "running" in the most liberal sense of the word. :)
Maybe I can help you get it up and running. What I did was use a fresh install of Ubuntu, updated it, then installed the rest of the packages as outlined in the user manual. Do note I had to over-ride the dependency on Omada < v4.0.0 to get Omada to install with MongoDB v4.4.3. Let me know if you have questions.
- Copy Link
- Report Inappropriate Content
I added an older repository of Mongo (3.6) and got up and running.
My frustration isn't just with the process being convoluted and the official instructions on the TP-Link website being insufficient, but the simple fact that, according to them, it relies on depricated and unsupported versions of packages and isn't yet supported on 20.04 LTS, even though its 8 months old already. By now, there should be a version of 4.x.x that works on Ubtuntu 20.04 LTS and officially uses a currently supported version of all of its dependencies.
- Copy Link
- Report Inappropriate Content
I completely agree.
May I ask the details of how you got an older repository of MongoDB to install on the Raspberry Pi? I only found a pre-compiled MongoDB 3.6 binary which claimed it works on Ubuntu 16.04, not 20.04. Ubuntu 18.04 is supported but only on x86 platforms, not ARM64. The instructions I followed are:
- From the offocial mongodb website - Docs - Server - Change Version 4.4 to 3.6 - Installation - Community Edition - Linux - Ubuntu.
They have a "Supported Platforms" link and further down the code required to install, which is what I used. Thanks in advance.
- Copy Link
- Report Inappropriate Content
https://help.ubuntu.com/community/Repositories/CommandLine
when you apt-get a repository, it creates a file in the /etc/apt/sources.list.d/ folder for each one.
they have one line in the file, which is the info on where to pull the repo from when you apt-get update.
like: deb [ arch=amd64,arm64 ] http://repo.mongodb.org/apt/ubuntu bionic/mongodb-org/3.6 multiverse
I changed "focal" to "bionic" so it would pull the version for the bionic beaver version of ubtuntu instead of focal fossa.
I also went down to 3.2 by changing the 3.4 file to pull from the older "jessie" version of debian.
I #commented out the original fine and changed from "xenial" 3.4 to "jesse" 3.2
#deb https://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 multiverse
deb http://repo.mongodb.org/apt/debian jessie/mongodb-org/3.2 main
I forget which one of these actually worked, but it let me control specifically which version of mongodb I was pulling.
Across the board, this shouldn't be what people need to do. Especially if you're using the current LTS release.
The fact that I have clients that won't connect to the running SDN is also infuriating. Jumping through all these hoops to get something that doesn't work. Grrrr.
- Copy Link
- Report Inappropriate Content
Thanks for the detailed explanation, it was helpful. If I summarize it, you pulled an earlier release (3.2 or 3.4) by using binaries compiled for previous versions of Ubuntu, in this case Ubuntu 16.04. (Xenial) I saw that option as well but didn't try it because I thought a binary designed for Ubuntu 16.04 may not run well on Ubuntu 20.04, but apparently I am mistaken. You also tried to grab an even earlier version of mongoDB (3.2) by taking a 2015 release for Debian. Again, I did not realize you could grab Debian versions of software and install them on Ubuntu. (which I guess makes sense since Ubuntu is based on Debian)
Did you by chance try to "Forget" one of your APs and configure it separately, then see if that difficult client could connect to it? That might tell you whether it's an issue with the Omada software or the firmware on the AP. Good luck, that is irritating!
- Copy Link
- Report Inappropriate Content
Thank you for explaining the proper term for what I did. I was just googling and trying. Had no idea that I was using the binaries.
Re: the access points, the issue with the firmware for the EAP225-outdoor and possibly the EAP225. I need to check the upgraded firmware on the EAP225. But that one is currently being managed by Omada Controller 3.2, which I no longer have installed on Ubuntu. So I don't want to break what seems to be working until I have a day to mess with the wifi without the wife and kids losing their minds.
On the "older" firmware of the EAP225outdoor (EAP225-Outdoor(US)_V1_1.20.0 Build 20200422), my difficult clients -- both chromebooks -- are not difficult. They'll connect to both the 2.4 band and 5g band when they are in standalone mode. When I upgraded to v 1.5 (EAP225-Outdoor(US)_V1_5.0.0 Build 20200918), I can no longer connect to the 2.4 band on the chromebooks. Everything else seems to connect fine.
What I need to check next is if the EAP225 firmware works the same way in standalone mode as the EAP225-outdoor. I need to figure out if bringing the EAP225-outdoor into the SDN controller and wireless network "corrupts" the network with its 2.4 band issues, or if they exist on the EAP225 when running independently in standalone.
I just hate "beta testing" software in my live environment. I don't have a separate network to mess with and solve these problems. Every time I crash my network with things that "should" work as advertised, my kids scream "Daddy broke the wifi again!" The biggest pain in the butt is the fact that the chromebooks aren't mine. They belong to two children that come to my house to do their online schooling. So I had no idea that my network was broken for a few days until they came over. But every other device in my house, including plenty of android devices and Google Home hardware, was working fine on the 2.4 band.
- Copy Link
- Report Inappropriate Content
Information
Helpful: 0
Views: 2883
Replies: 7
Voters 0
No one has voted for it yet.