toltec
toltec copied to clipboard
Automate re-enabling of Toltec after system upgrades
when opkg/toltec is installed and there is a system upgrade, we need a way to re-enable opkg. the entware package comes with entware_reinstall which re-creates the opt mounting system service. i believe our bootstrap script (thanks linusCDE!) automatically re-enables the opkg as well. (is the bootstrap script saved locally for re-use after upgrade?)
currently, we do not have any hooks into the remarkable's upgrade process to automatically re-enable opkg.
options:
- try to get hook in upgrade process
- add something to .bashrc (or similar) that notifies user when they ssh in that opkg isn't enabled and print way to re-enable it
- ???
The current bootstrap script creates a script called entware-reenable
in the home folder, and shows “Use '/home/root/entware-reenable' to re-enable Toltec after a system update” to the user after install. Automatically detecting in .bashrc when it needs to be run seems like a good idea.
I think @Eeems had the idea to add a specific feature to reMarkables update_engine. One would need to:
- Add the feature to their update_engine
- Create a PR there
- Hope that they merge it
Maybe creating an issue there would be a better first step, to ask if they would even want to allow such a feature.
Have we found a way to downgrade to a previous version to test the upgrade path? The only way I know of currently is flashing using uuuflash.
Flashing a previous version to the other root partition while live and then switching partitions.
Do you know if this is documented somewhere?
Do you know if this is documented somewhere?
Not that I'm aware of.
Update: This is now easily doable thanks to ddvk’s remarkable-update project (works on rM1 and rM2).
https://github.com/Jayy001/codexctl implements full on-device upgrade/downgrade handling, and would be extendable to run post-upgrade scripts for us. At some point soon, I'll add codexctl as a toltec package for us when I sort out automating the build for the device binary.
Something I noticed recently, run-postinsts.service
is part of the sysinit.target
, which appears to run scripts in /etc/ipk-postinsts
. So this might be how we hook in post install scripts easily.
You can use the following to turn on logging to /tmp/postinst.log
echo "POSTINST_LOGGING=1" > /etc/default/postinst
echo "LOGFILE=/tmp/postinst.log" >> /etc/default/postinst
We should probably put a service in place that waits for opt.mount
and then runs opkg configure
if there isn't already. This script looks like it would run opkg configure
if it was installed on the base system. I believe entware has default installed packages for other init systems that we should double-check t osee if we should be integrating somehow. Similar to how the profile stuff wasn't being loaded.
@Jayy001 you should be aware of this issue