-
Notifications
You must be signed in to change notification settings - Fork 0
Design considerations
There are challenges that come with allowing live composition of the operating system image, and below are how ostree-sysext addresses them:
Under ostree-sysext, each extension should be built directly atop the base image, duplicating dependencies as required. Thanks to OSTree's inherent deduplication, this carries a minimal storage space impact.
The plugin system is provided as a means for a package manager, which is aware of potential conflicts, to object to system extensions being layered.
The requested combination is audited as a full set of the base image deployment, and all system extension deployments to be layered on top, ensuring full compatibility.
This responsibility is again offloaded to the plugin system. When updating the base image, or the set of extensions being layered on top, all installed plugins are summoned to audit the combination and give their approval.
The intent being that distro-agnostic system extensions can be distributed, such as software that installs into /opt, and those may not need to be checked for conflicts.
One advantage of ostree-sysext over rpm-ostree for instance, is that extensions being layered at run time, in the event that boot fails, ostree-sysext can fall back to not loading extensions, leaving the user with a pristine base image.
UAPI system extensions can be applied on boot, but given that ostree-sysext uses the volatile /run/extensions deployment space, the set of system extensions that it defines does not exist on boot.
To this end, an OSTree commit representing the combination of system extensions, as well as the resulting state files, is stored in /ostree/deploy/<osname>/extensions/deploy, and loaded by the initramfs on boot.
Additionally, the extension set to be loaded on boot is bound to a specific OSTree deployment via a symbolic link in /ostree/deploy/<osname>/deploy/<hash>.<0 or 1>.extensions