Blueos automaticly changes to factory version when the power off than restart the raspberry pi 4b blue os version changes automaticly to factory version from blue 1.1.0 beta 16.
I’ve had this happen twice now. I was running BlueOS Master today, but was also running Beta 18 at some point a few weeks back and on two occasions things have stopped working (mainly the Cerulean DVL extension is how I noticed it), and found that I was back on factory from 12 months ago. I’m sorry I don’t know what’s causing it but would love to know.
Sorry for the delay on responding to this.
This is a known issue and we’re working on trying to resolve it, as well as make it easier to work around.
For some context, the BlueOS-core Docker image (which runs most of the BlueOS functionality) gets started and monitored by a service we call “bootstrap”, and it’s not yet possible to update bootstrap (nicely) through BlueOS (the normal BlueOS version updater only updates the core image). If BlueOS (core) somehow dies during operation then its bootstrap’s job to revert to a known working image (currently just the one tagged as factory, which is whatever it was first flashed with) so that it’s at least possible to access the interface.
We made some improvements to bootstrap in BlueOS-1.1.0-beta.20, so installing that or a later release may help with the factory reset problem, but currently the new image would need to be flashed onto the SD card in order to get the new bootstrap version, or bootstrap will need to be updated manually through the Terminal page:
# drop down from blueos-core into the underlying operating system:
red-pill
# get the running bootstrap container id
CURRENT_BOOTSTRAP_CONTAINER=$(docker ps -aq --filter name=blueos-bootstrap)
# stop the bootstrap container (takes 10 seconds)
docker stop $CURRENT_BOOTSTRAP_CONTAINER
# remove the container from local memory
# (the underlying image remains on the system, unused)
docker container rm $CURRENT_BOOTSTRAP_CONTAINER
# specify the new version to use (e.g. 1.1.0-beta.21, or master)
NEW_BOOTSTRAP_VERSION=1.1.0-beta.21
# start running the new version
# (will automatically download if it's not already available locally)
docker run \
-t \
--restart unless-stopped \
--name blueos-bootstrap \
--net=host \
-v /root/.config/blueos/bootstrap:/root/.config/bootstrap \
-v /var/run/docker.sock:/var/run/docker.sock \
-e BLUEOS_CONFIG_PATH=/root/.config/blueos \
bluerobotics/blueos-bootstrap:$NEW_BOOTSTRAP_VERSION
# once running it should start repeatedly printing
# "core is already running, waiting for it to stop..."
# press ctrl-c to return to the terminal, and you're done
2 Likes
Thanks. I’ll give it a try and let you know how it goes. Cheers Matt
Hello,
I’ve started seeing this same message on my BlueOS terminal for the BlueBoat:
“This vehicle is running its “factory” version of BlueOS. This generally means something went wrong, and the system reverted to this version in order to recover. Please file an issue at BlueOS/issues or post on our forum. Please include the System logs if possible, and what you were doing when this happened.”
I’m not sure when exactly this first popped up, but the BlueOS version is 1.1.0-0 and the Bootstrap Version is 1.1.0. I tried to attach my logs, but the forum doesn’t seem to allow .zip attachments.
Please advise on if this is an issue and how to resolve if it is.
Thanks,
Gabe
Hi @gabedbv,
If the vehicle and software are running as expected then being in the factory version isn’t a problem, but it does indicate there was some kind of issue when it tried to start up in a normal BlueOS image that caused it to fall back to its factory one.
If 1.1.0 is the latest BlueOS version you’ve installed then reverting to a 1.1.0 factory image is unlikely to have a notable impact. If you’ve installed a more recent version (e.g. BlueOS 1.1.1 or BlueOS 1.1.2-beta) then you might notice that the newest features from those updates are missing until you either switch to your installed version from the BlueOS Version page (Pirate Mode is required to see your installed versions), or if you reboot the Raspberry Pi and it manages to start BlueOS normally (without reverting to factory).
Sorry about that - I’ve just added .zip to the allowed file extensions.
If it’s not happening regularly then it shouldn’t be an issue. If it is happening consistently then it could be a problem, in which case it would be good if you could provide some logs for us to look into 
I frequently see this issue as well. If I upgrade BlueOS it will eventually downgrade itself back to the factory version. One solution is to re-flash the SD card with a fresh BlueOS Raspberry Pi image.
My solution is to go into a terminal and use docker tag to tag the newest version of blueos-core as factory. Then when it factory resets, it will reset to the current version.
1 Like
That’s a great solution! We’re testing the fix for a more permanent solution now, and will release soon!