I am a designer for an embedded device and am investigating ostree. I have some questions that I have not been able to find answers for.
My device has an A/B partition update scheme currently (plus third data partition), and it's mandatory that the currently active partition be read-only at the flash/hardware level. I'm trying to understand what value, if any, we could get from moving that partition to ostree with a deployment created when we create the rootfs. If we do not make this partition writable, (ie. staying with squashfs), I'm not quite seeing obvious value in moving over to ostree. Is there something I'm missing?
Next, if we move to f2fs-on-loopback (we need compression, cant change underlying ext fs at this point), we still cant write to the system while it is running. I can anticipate that we could use a system where we can stage updates and verify/install updates into the repo in the initramfs before we activate hardware write-protect. This is also not ideal though, because one guarantee that we want to protect is that you never get into a situation where both partitions become corrupt/unbootable. (I could construct a situation where 'B' partition is already corrupt, then installing something in the current image corrupts things rendering the entire system unbootable. I suppose that retaining and falling back to a previous deployment could solve a few different issues, not likely all, though) Is there anything I'm missing here?
So why am I looking at ostree? I have several use cases:
- On a locked-down device, run all system services from ro-rootfs. Have full attestation that the device is running unmodified vendor code.
- On development systems (which we have an existing process to cryptographically unlock), would like to be able to let developers install updated packages/files
- On customer systems, want to be able to:
- install vendor-signed packages that would be completely separate applications (not replacing/updating any existing files)
- install vendor-signed packages that replace/update base-os components
- policy controlled way to install third-party signed applications, and control by policy if those third party apps are separate apps or replace/update base os components
- policy-controlled way to install self-signed applications the same way as above.
- ideally: the 'developer' flow above and the 'customer system' flow would be identical.
To me, what seemed to make sense to solve for these would be something like:
- best solution would be a way to have split repositories?
- Is there a way to use symlinks for deployments?
- is there a way to use overlayfs? Base-os as lowest layer, directory on the data partition as upper/work layers. Then deployments can be on the overlayfs.
- solve use case for locked down system by only allowing base os daemons to run from deployment on the read only rootfs.
- plugins can run from the overlayfs
- if enabled, if there is an installed update for base os daemons, those can be run from the overlayfs.
Is any of the above viable or are there better solutions?
Next, I was investigating flatpak, which looks like it's built on top of ostree. I'm thinking that (conceptually) we can take the base os on our device and have it set up as basically just systemd and dbus, and run all daemons out of separate application deployments. Is this straightforward to do with base ostree or does flatpak bring value here that we should be looking at? We dont need things like desktop integration or such that flatpak seems to focus on. It's unclear to me how much of this I can easily do with base ostree tools or how much I should be looking at flatpak.
Any info here would be much appreciated! I've been reading up all the docs I can see to understand these issues, but it seems like my use case is a bit niche and not discussed much.
--
Michael Brown
