Detailed step by step instructions to reproduce the problem
Removed the rockon, then the almost-always-happens happened and docker was removed but db was left out-of-sync, ran delete-rockon which seemed to fix it. Reinstall didn’t work and after reboot (to fix another problem) I got this error.
Agreed. We have some work to do in this area and have actually made a bit of progress of late also but we edge ever close to that is actually still a little fragile. Many moving parts and all that.
I.e. choose another one and switch the system over to using that one. I.e. a “rock-ons-root2”. Switching the Rock-ons service off first and then re-configuring it to use the new one before switching it back on again. This can side step some issue that we have yet to make more robust. Plus no actual config or data is challenged by this, assuming all Rock-ons installed have been configured as recommended, i.e. with individual config/data shares.
Let us know if this brute force approach works for you. I’ve had to do it a hand-full of times over the years myself when time did not permit deeper examination. Or when I just needed a fresh start on the Rock-ons system - testing etc.
Changed the root, rebooted, no help, changed it back so I could get the installed rockons to start. I guess I have some greater db problem there. (Maybe related to the other thread)
From here on the intent was to re-setup your Rock-ons - using the existing config and data shares. It really can help to side-step some as yet unresolved issues. You are then starting from scratch for your Rock-ons setup and will have to wipe via command line existing ones but there-after you re-establish (as you re-install) the expected consistency.
Which re-instates your reported inconsistencies. I was attempting to offer a re-set option here. This is not a fix for your setup, but a re-setup option that could provide a work-around with little effort.
Which a reset to new state (via new Rock-on-root) can help to establish. Along with wiping all Rock-ons via command line.
Yes, potentially. If our command line db wipe-per-Rock-on is not coping with your previous custom json entries having taken things out-of-scope (at least current scope).
Hope that helps, at least form clarifying the intention here. We likely need to document this Rock-ons reset procedure and this thread has helped to highlight that need. Cheers.
