I manage 2 offices running BlueCherry. I recently fixed an error at the Primary office, but now am having a frustrating issue at the secondary office.
MySql service is restarting every 10 seconds or so. It is the only docker container running, and has the only MySQL server in that office.
Output of ‘docker compose logs bc-mysql’:
bc-mysql | Fatal glibc error: CPU does not support x86-64-v2
bc-mysql | Fatal glibc error: CPU does not support x86-64-v2
bc-mysql | Fatal glibc error: CPU does not support x86-64-v2
bc-mysql | Fatal glibc error: CPU does not support x86-64-v2
bc-mysql | Fatal glibc error: CPU does not support x86-64-v2
bc-mysql | Fatal glibc error: CPU does not support x86-64-v2
bc-mysql | Fatal glibc error: CPU does not support x86-64-v2
bc-mysql | Fatal glibc error: CPU does not support x86-64-v2
bc-mysql | Fatal glibc error: CPU does not support x86-64-v2
bc-mysql | Fatal glibc error: CPU does not support x86-64-v2
bc-mysql | Fatal glibc error: CPU does not support x86-64-v2
bc-mysql | Fatal glibc error: CPU does not support x86-64-v2
bc-mysql | Fatal glibc error: CPU does not support x86-64-v2
bc-mysql | Fatal glibc error: CPU does not support x86-64-v2
bc-mysql | Fatal glibc error: CPU does not support x86-64-v2
bc-mysql | Fatal glibc error: CPU does not support x86-64-v2
bc-mysql | Fatal glibc error: CPU does not support x86-64-v2
bc-mysql | Fatal glibc error: CPU does not support x86-64-v2
bc-mysql | Fatal glibc error: CPU does not support x86-64-v2
bc-mysql | Fatal glibc error: CPU does not support x86-64-v2
bc-mysql | Fatal glibc error: CPU does not support x86-64-v2
bc-mysql | Fatal glibc error: CPU does not support x86-64-v2
bc-mysql | Fatal glibc error: CPU does not support x86-64-v2
bc-mysql | Fatal glibc error: CPU does not support x86-64-v2
bc-mysql | Fatal glibc error: CPU does not support x86-64-v2
bc-mysql | Fatal glibc error: CPU does not support x86-64-v2
bc-mysql | Fatal glibc error: CPU does not support x86-64-v2
bc-mysql | Fatal glibc error: CPU does not support x86-64-v2
bc-mysql | Fatal glibc error: CPU does not support x86-64-v2
bc-mysql | Fatal glibc error: CPU does not support x86-64-v2
bc-mysql | Fatal glibc error: CPU does not support x86-64-v2
bc-mysql | Fatal glibc error: CPU does not support x86-64-v2
bc-mysql | Fatal glibc error: CPU does not support x86-64-v2
bc-mysql | Fatal glibc error: CPU does not support x86-64-v2
bc-mysql | Fatal glibc error: CPU does not support x86-64-v2
Are you using Proxmox? Change the CPU to “host”.
Also…I know the docker version might be appealing…but please use the package versions for mission critical setups.
I use Proxmox at home only. This is setup at work. It is on a bare metal system running Debian Bookworm.
Any other ideas?
Proxmox is not used at this location. Bare metal install on Debian 12. I have only ssh access to this site. Physical access is very seldom.
Can anyone advise if this issue can be triaged as-is, or do we need a newer machine?
Currently, I only have ssh access. I can make a special trip down there if needed. I just would like to know what to tell the bosses?
Current OS is Debian 12 “bookworm”. Unless the normal install has added support, I am unable to install bluecherry.
We should have Debian 12 packages ready for testing in the next week. As I mentioned earlier in the post docker isn’t recommended for production so once the Debian 12 packages are ready you should run ‘docker compose stop’ and ‘docker compose down’ then install the packages
What preparatory procedures will I need to perform in order to migrate from Docker to a “normal” install?
I tried to backup the config to a local computer via the database backup option, but no matter how many I input the 100% correct password for the bluecherry database user, it gives an authentication error.
I was able to dump the bluecherry database with mysqldump (with the EXACT SAME password, mind you) running via docker exec, and piping the output through tee to a file on the docker host system. I’m not sure if that helps in my endeavor or is needed?
The actual recordings are stored on a separate internal HDD I don’t expect to have issues reestablishing the recordings.
Just a point of curiosity: What are the system requirements to run BlueCherry?
The machine at the secondary location has a Core2Duo E7500 CPU, with 4 GB RAM (2x 2GB), running with 3 cameras (4th camera is disabled, due to a hungry rodent and a now broken interface cable)
@curtishall I suppose you’re busy getting the release ready?
I’m still not clear how to migrate my mysql DB from docker to native environment.
That’s the problem, this CPU was discontinued 15 years ago. It doesn’t support all of the AMD64 instruction set that docker requires.
Make sure versions are the same. From the docker environment change directory to bluecherry-docker and run:
docker exec -it bc-server mysqldump -h bc-mysql bluecherry >> bluecherry-full.dump
Copy bluecherry-full.dump to the new install. Do a clean install of Bluecherry server, make sure to note the admin password that you create, then run this:
sudo service bluecherry stop
sudo mysql bluecherry < bluecherry-full.dump
sudo service bluecherry start
This should take care of the database import.
Ok. I am more or less aware of this. I let the boss know that we need a newer machine, and we are going to work on that this week, I believe. We have newer machines around, collecting dust. Just need to take the time to install Linux, and configure the system.
Just to be clear however, docker itself didn’t complain about the CPU features - it was the mysql executable running inside of docker. In theory that would occur whether mysql is running on bare metal vs. docker.
As for the DB export/import, that’s pretty much what I suspected. I did a test run of a slightly modified command from what you posted. (I think I used the tee command to verify that the output was text, and didn’t contain an error message, etc.) instead of simply sending the output to a file. I also specified the user and had it prompt for the password for mysqldump command, but it appears that isn’t necessary…
I will dump the database and then stop the docker container, then run the bluecherry install script. I can remove the defunct images and volumes afterward and rm the docker folder.
Apologies. I think I inadvertently may have caused some confusion. Probably Moot, but still want to clarify that I’ve been tossing around 2 different servers as though they were the same.
Secondary location has the old machine with the 15 year CPU. BlueCherry hasn’t worked there for about 4 months, so there is nothing to really migrate there. Just going to do a fresh install on the new server. That location has a static IP from the ISP and only 4 cameras, so using the community version.
Primary location has the info to migrate. Going to go from docker to bare metal as soon as the updated installer is released. Using my system that I originally built for BlueCherry. I sold it to them for their surveillance use and also as a docker host for a few small projects.
Personally, I now use a proxmox system at hone with Frigate doing the video decoding/processing via the go2rtc module and then splitting the processed video to both BlueCherry and to itself for object detection.
Again, probably not so interesting.
