Recovery from corrupt resin-supervisor database

A remote Pi running 2.47.0+rev1 lost key files in several containers, possibly due to power loss. It remains remotely accessible through OpenBalena, but I cannot find a way to rebuild the containers or replace them with a newer version (remains at the same version following upgrade via API). The supervisor process itself appears to be affected, with systemctl status resin-supervisor showing:

Aug 21 05:38:53 823cdaf resin-supervisor[8498]: Starting system message bus: dbus.
Aug 21 05:38:53 823cdaf resin-supervisor[8498]:  * Starting Avahi mDNS/DNS-SD Daemon: avahi-daemon
Aug 21 05:38:53 823cdaf resin-supervisor[8498]:    ...done.
Aug 21 05:38:58 823cdaf resin-supervisor[8498]: [info]    Supervisor v10.6.27 starting up...
Aug 21 05:38:59 823cdaf resin-supervisor[8498]: (node:1) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the>
Aug 21 05:38:59 823cdaf resin-supervisor[8498]: (node:1) UnhandledPromiseRejectionWarning: Error: SQLITE_CORRUPT: database disk image is malformed
Aug 21 05:38:59 823cdaf resin-supervisor[8498]: (node:1) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing i>
Aug 21 05:38:59 823cdaf resin-supervisor[8498]: (node:1) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejecti>

This seems to be referring to database.sqlite, in which a plaintext dump shows readable text interspersed with large unreadable sections. Not sure how to properly access the database since neither sqlite nor common tools for installing it appear available on the BalenaOS host and inside the supervisor container. Is there any way to remotely repair or recreate the supervisor or the application containers, perhaps by replacing the database and upgrading once it is stable? I am fine with losing any current data short of the VPN connection.

Hey @mber, you can delete the existing supervisor database and it will be recreated based on the last target state in the cloud.

systemctl stop resin-supervisor
rm -v /mnt/data/resin-data/resin-supervisor/database.sqlite
systemctl start resin-supervisor

Afterwards you may notice some logs indicating images are being downloaded, but if possible it will still use the engine cache.

Many thanks @klutchell ! The host system had already been replaced, but I will try that out as soon as I can get the disk image, and it is good to know that the supervisor’s database is flexible.