View previous topic :: View next topic |
Author |
Message |
dewhite Tux's lil' helper
Joined: 16 Mar 2003 Posts: 106 Location: Houston, Texas, USA
|
Posted: Mon Nov 23, 2020 10:25 pm Post subject: [SOLVED]Temporarily downgrade Mongodb to masked 4.0.X |
|
|
Hello all,
It seems I've made a little mess. I run Unifi Controller on two Gentoo systems (home and small business). I recently upgraded both setups to version 6.1.21 during World updates, which pulled in an update of Mongodb from 3.6.X to 4.2.8. After the updates, I later noticed that Unifi Controller isn't starting, and I troubleshot that to an error in /var/log/unifi/mongodb.log that reads, in part:
Code: | 2020-11-23T15:32:52.803-0600 F CONTROL [initandlisten] ** IMPORTANT: UPGRADE PROBLEM: Found an invalid featureCompatibilityVersion document (ERROR: BadValue: Invalid value for version, found 3.6, expected '4.2' or '4.0'. Contents of featureCompatibilityVersion document in admin.system.version: { _id: "featureCompatibilityVersion", version: "3.6" }. See https://docs.mongodb.com/manual/release-notes/4.2-compatibility/#feature-compatibility.). If the current featureCompatibilityVersion is below 4.0, see the documentation on upgrading at https://docs.mongodb.com/manual/release-notes/4.2/#upgrade-procedures. |
Easy, right? Just read the docs and upgrade the db file. Small wrinkle - Mongodb seems to require that 3.6 be upgraded to 4.0, then 4.0 to 4.2. OK, no problem...
Wait. All 3.6.X and 4.0.X packages have been masked, because:
Code: | Mask dev-db/mongodb versions which do not support python3 so we can move forward in cleaning python2 from tree. Bug #708954. We keep the ebuilds available since some of those versions are still supported by upstream. See: https://jira.mongodb.org/browse/SERVER-52687
Affected packages
<dev-db/mongodb-4.2.8
Author/Date
Alexys Jacob <ultrabug@gentoo.org> (2020-11-09 00:00:00 +0000 UTC) |
Before I started monkeying around under the hood to try to bypass the masks and "downgrade" to a 4.0.X package temporarily, I thought I'd ask for any practical advice the community is willing/able to offer.
Bonus Points: I've already completed the update to Profile 17.1 on one of these systems (of course, on the system with the more elaborate and critical Unifi setup). The other is still on Profile 17.0. Not sure if that matters, but it seemed at least tangentially related...
As always - any thoughts, suggestions, questions, references, rants, etc. will be greatly appreciated.
Thanks,
Dan _________________ Work FS: R7-5700g | 2x16Gb DDR4 | 500Gb NVMe LUKS root | 2x 8TB RAID1
Home FS: R7-1700x | 2x8Gb DDR4 | 275Gb M.2 SATA LUKS root | 2x 14TB RAID1
Last edited by dewhite on Tue Nov 24, 2020 7:38 pm; edited 1 time in total |
|
Back to top |
|
|
Stein0815 n00b
Joined: 24 Nov 2020 Posts: 2
|
|
Back to top |
|
|
Hu Administrator
Joined: 06 Mar 2007 Posts: 22729
|
Posted: Tue Nov 24, 2020 4:58 pm Post subject: |
|
|
If you prefer to handle this through Portage, bypassing the masks should be relatively simple. Whether the resulting build will work is not guaranteed, but we can try to help you fix it if needed. |
|
Back to top |
|
|
dewhite Tux's lil' helper
Joined: 16 Mar 2003 Posts: 106 Location: Houston, Texas, USA
|
Posted: Tue Nov 24, 2020 5:11 pm Post subject: |
|
|
Ingo,
I see that you joined the forum and made your first post to answer my question. You are a scholar and a gentleman, Sir!
Your post put me on the right path, and after a little tinkering, my problems are resolved.
For any future souls that happen by, I thought I'd give a little more detailed description of what I needed to do:
Code: | cd ~
wget https://fastdl.mongodb.org/linux/mongodb-linux-x86_64-4.0.21.tgz
tar -xvf mongodb-linux-x86_64-4.0.21.tgz
cd mongodb-linux-x86_64-4.0.21/bin
sudo -u unifi ./mongod --noauth --dbpath /var/lib/unifi/data/db |
While the server is running, open a separate shell:
Code: | /etc/init.d/unifi stop
/etc/init.d/mongodb stop
cd ~/mongodb-linux-x86_64-4.0.21/bin
./mongo
db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )
db.adminCommand( { setFeatureCompatibilityVersion: "4.0" } )
db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )
db.adminCommand({ "shutdown" : 1 })
exit |
Now the db needs to be updated from 4.0 to 4.2, using the installed binaries, instead of the ones temporarily downloaded.
In the first shell, notice the lack of "./" before mongod:
Code: | sudo -u unifi mongod --noauth --dbpath /var/lib/unifi/data/db |
In the second shell, similar lack of "./" this time:
Code: | mongo
db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )
db.adminCommand( { setFeatureCompatibilityVersion: "4.2" } )
db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )
db.adminCommand({ "shutdown" : 1 })
exit |
Now, to clean-up, in whichever shell you like:
Code: | /etc/init.d/mongodb start
/etc/init.d/unifi start
cd ~
rm -R mongodb-linux-x86_64-4.0.21*
exit |
_________________ Work FS: R7-5700g | 2x16Gb DDR4 | 500Gb NVMe LUKS root | 2x 8TB RAID1
Home FS: R7-1700x | 2x8Gb DDR4 | 275Gb M.2 SATA LUKS root | 2x 14TB RAID1
Last edited by dewhite on Wed Nov 25, 2020 9:43 pm; edited 3 times in total |
|
Back to top |
|
|
dewhite Tux's lil' helper
Joined: 16 Mar 2003 Posts: 106 Location: Houston, Texas, USA
|
Posted: Tue Nov 24, 2020 5:13 pm Post subject: |
|
|
Hu wrote: | If you prefer to handle this through Portage, bypassing the masks should be relatively simple. Whether the resulting build will work is not guaranteed, but we can try to help you fix it if needed. |
Hu,
Thank you, also, for the offer to help. My issue appears to be resolved on one system. If I encounter different issues on the other, I will check back in for more assistance.
Thanks,
Dan _________________ Work FS: R7-5700g | 2x16Gb DDR4 | 500Gb NVMe LUKS root | 2x 8TB RAID1
Home FS: R7-1700x | 2x8Gb DDR4 | 275Gb M.2 SATA LUKS root | 2x 14TB RAID1 |
|
Back to top |
|
|
Stein0815 n00b
Joined: 24 Nov 2020 Posts: 2
|
Posted: Tue Nov 24, 2020 10:00 pm Post subject: |
|
|
Hi Dan,
thanks for your kind words. :-) Indeed I created an account just to answer your question.
I got so frustrated with this problem I could not resist to post a possible solution ;-)
Having cleaned up the huge python 2 mess on my system recently, I was not amused to find out I'd need to roll back to MongoDB 4.0.x needing Python 2.7 when using the portage.
Hu, I'm not aware of how to bypass Python 2.x as MongoDB has no resp. USE flag?
Luckily the binary did the trick.
Regards
Ingo |
|
Back to top |
|
|
Hu Administrator
Joined: 06 Mar 2007 Posts: 22729
|
Posted: Tue Nov 24, 2020 11:43 pm Post subject: |
|
|
Stein0815 wrote: | Hu, I'm not aware of how to bypass Python 2.x as MongoDB has no resp. USE flag? | There may not be a way to eliminate the Python 2 dependency, but that does not mean we cannot get the old Mongo to build. It just makes it a bigger challenge. |
|
Back to top |
|
|
sidamos Apprentice
Joined: 16 Dec 2007 Posts: 246
|
Posted: Sat Dec 05, 2020 4:30 pm Post subject: |
|
|
I have a similar problem. I am currently on masked MongoDB 3.6.17 because of Unifi.
I think, I could migrate to 4.2 by backing up the db under 3.6.17 and restoring it under 4.2 or going your route.
My main concern is: Is Unifi working OK with MongoDB 4.2? |
|
Back to top |
|
|
Akaihiryuu l33t
Joined: 08 May 2003 Posts: 794 Location: Columbus, OH
|
Posted: Sat Dec 05, 2020 11:52 pm Post subject: |
|
|
My main concern with this is that ubiquiti themselves have stated that unifi currently only supports 3.6. I don't really understand what people are doing to get it to work under 4.0 or 4.2...because according to them it doesn't work. So is this actually working? |
|
Back to top |
|
|
Akaihiryuu l33t
Joined: 08 May 2003 Posts: 794 Location: Columbus, OH
|
Posted: Mon Dec 07, 2020 7:53 pm Post subject: |
|
|
I did this and it works, omg. Despite Ubiquiti insisting it won't work with anything higher than 3.6.
Question...will this work for Mongo 4.4 too? Just follow the last part of the directions, swapping 4.4 for 4.2 and 4.2 for 4.0?
EDIT: Can't get the instructions to work for 4.4, I guess syntaxes have changed. I know next to nothing about mongodb. It "sort of" works with 4.4 but the log file looks really bizarre, showing things like $t instead of the date/time, and raw data instead of being formatted correctly.
It shouldn't matter though, 4.2 should be current and useable on Gentoo for quite awhile which solves my original problem.
Last edited by Akaihiryuu on Mon Dec 07, 2020 10:00 pm; edited 1 time in total |
|
Back to top |
|
|
sidamos Apprentice
Joined: 16 Dec 2007 Posts: 246
|
Posted: Mon Dec 07, 2020 8:43 pm Post subject: |
|
|
Another, maybe easier migration to newer MongoDB versions (given that Unifi works with it) is to backup the Unifi data from the web interface and start with a fresh MongoDB and restore the Unifi data. |
|
Back to top |
|
|
Ionen Developer
Joined: 06 Dec 2018 Posts: 2870
|
Posted: Tue Dec 08, 2020 1:17 pm Post subject: |
|
|
Akaihiryuu wrote: | Despite Ubiquiti insisting it won't work with anything higher than 3.6 | May want to see this comment from the ebuild maintainer saying that even the latest unstable mongodb is tested (you can use 4.4.x, not that I'm familiar with the migration process myself).
So for anyone else that hasn't, try to migrate away from 3.6.x sooner than later. |
|
Back to top |
|
|
sidamos Apprentice
Joined: 16 Dec 2007 Posts: 246
|
Posted: Tue Dec 08, 2020 5:18 pm Post subject: |
|
|
OK, so I made a backup from within Unifi and reinstalled Unifi and MongoDB (4.4.1, stable for Gentoo) from scratch (deleted data files of Unifi and MongoDB) and then restored the backup. It works.
Unifi itself sets the compatibility level for MongoDB to 3.6.
So, the only problem in migrating from 3.6 to 4.4 is if one wants to migrate via the MongoDB database (without Unifi backup/restore), which means migrating over version 4.0 to 4.4. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|