-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Explore building a custom system image #27
Comments
This may potentially make #21 easier too. |
I'm personally unsure if we should do it. While this makes the software more uniform, it makes it harder for newbies/tinkerers or devs that want their sw on toltec as well. I'm also concerned that we would mess with one of reMarkables own safe-guards (the rollback) and thus could potentially brick devices. Meddeling with updates and uninstalling toltec will also get much harder. I'm not sure if the increased stability of toltec-software is worth the risk the increased install/reenable/uninstall burden this would add. I'm not against the idea of building our own oe-image at all though. While we take a bit more space, using a chroot which is partition independent seems like a better middle ground for me personally. For example, we could have the oe-image installed to e.g. |
It would actually get easier. Just reflash with the official image.
In my opinion it would be. I'd like to be able to take xochitl updates without breaking all my other stuff. This would be a mechanism to do that. We could run the system image in a chroot or something and flash updates without breaking all the other apps. And install/uninstall would become easier, and there is no longer a need for reenable. |
You mean with the flash utilities?
Ok. I think that I don't fully understand the goal then, yet. It is cool if we can ditch the reenable though. Since I don't fully understand it, I'm not in a position to doubt this decision and I should probably just let it happen. Just curious: Would this change the scope of toltec from a packagemanager/repo to a fully blown distro that devices could run instead? |
That or just booting into the other root partition and writing the official image to the other partition. We'd probably want to create some tools to simplify things.
This is probably a ways off still. We'd have to figure out the whole image first and what is required etc. Plus we'd have to sort out how to run the chroot with the official image for running xochitl and having it play nice still.
Yes it likely would. That's why this issue is titled "explore" and not "implement". There is a lot of things we have to sort out first to see if it's worth it. I do think in the end it might be though. |
Instead of installing apps in the
/opt
folder of the stock system, we could build a custom system image with OpenEmbedded/Yocto and take advantage of the dual-partition setup to install our image in a partition while keeping the official image in the other. The company has published some of the recipes used to build their OE image:This could allow us to control the libraries included on the system and to more easily create the build toolchain since OE can export a toolchain automatically IIRC.
The text was updated successfully, but these errors were encountered: