Disable deletion of files outside /mnt/managed_home directory

Hello, we are installing a third-party SDK on our brain. This SDK installs dependencies and files into a different directory than the /mnt/managed_home.

We found that our installed files got deleted when we rebooted the brain as it seems that any changes outside of /mnt/managed_home get reset upon reboot.

We were wondering if there’s any way to disable this feature as it has caused us quite a few issues so far. Thank you!

Hello @CSArjun ,

Can you please explain in more detail what you are installing? E.g., pip packages, apt packages, source code, etc.

Additionally, can you expand on what the issues you are encountering are?

This will help us in supporting you on this topic.


We are installing an SDK to integrate a hyperspectral camera with the brain called Ebus SDK. The Ebus SDK is a .deb package and requires installation of libavcodec58, QT5, libyaml-cpp0.6 as well.

The final part of the installation requires us to reboot the brain so the SDK can setup the environment variables.

The SDK installation is downloaded by default to the following directory: opt/pleora/ebus_sdk/<distribution_targeted>/

However, we noticed that when we rebooted the brain, the entire pleora folder had disappeared. Same with QT5, libyaml-cpp, I couldnt find them either. Another dev working with the Amiga brain told us that any files we make outside /mnt/managed_home get deleted upon reboot. Can you confirm if that’s the case please? Or how we might go about troubleshooting what’s the issue?

Hello @CSArjun ,

Can changes outside of /mnt/managed_home/ persist?

Yes this is true and is an important aspect of our OS infrastructure. We ensure a clean slate every reboot, so every brain boots into the same state every time. This also ensures software updates are successful and do not conflict with any custom installed packages.

Required reboot

You should be able to get around this requirement. The reboot is likely more of a big red button that forces environment variables to update, services to restart / reload, the shell to re-login or restart, kernel modules to load, etc.

If you can determine what changes from a reboot are required, you can manually apply / force them to occur.

On our side

This is operating outside of what is supported with our current architecture. We will evaluate this use case and see if it is something we can support in the future.


In the meantime, see if you can manually force the required changes a reboot would cause. Once you have this, you can create a service in your /mnt/managed_home/ directory that runs a bash script that performs the installation steps on every boot. You may also be able to copy the manually compiled package from /opt into /mnt/managed_home/ so it persists and copy it back into /opt on every boot, which would speed up the install on each boot significantly.

I hope this helps,