Skip to content
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

Open
matteodelabre opened this issue Mar 19, 2021 · 5 comments
Open

Explore building a custom system image #27

matteodelabre opened this issue Mar 19, 2021 · 5 comments
Labels
ideas Ideas that need to be explored

Comments

@matteodelabre
Copy link
Member

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.

@matteodelabre matteodelabre added the ideas Ideas that need to be explored label Mar 19, 2021
@matteodelabre
Copy link
Member Author

This may potentially make #21 easier too.

@LinusCDE
Copy link
Member

LinusCDE commented Mar 20, 2021

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. /home/root/.toltec-oe-root and have bind-mounts from that directory to the real /opt, /home, /dev, /proc, /sys. Software that requires predictable libs like qt could then run in the chroot of /home/root/.toltec-oe-root which would basically behave as the normal device except the predictable libs in their assumed /lib and so on. This may come at a cost of somewhere around 100MB more storage usage though.

@Eeems
Copy link
Member

Eeems commented Mar 20, 2021

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.

It would actually get easier. Just reflash with the official image.

I'm not sure if the increased stability of toltec-software is worth the risk the increased install/reenable/uninstall burden this would add.

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.

@LinusCDE
Copy link
Member

It would actually get easier. Just reflash with the official image.

You mean with the flash utilities?

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.

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?

@Eeems
Copy link
Member

Eeems commented Mar 20, 2021

You mean with the flash utilities?

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.

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.

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.

Just curious: Would this change the scope of toltec from a packagemanager/repo to a fully blown distro that devices could run instead?

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ideas Ideas that need to be explored
Projects
None yet
Development

No branches or pull requests

3 participants