POC: systemd-sysext use via addons #7450
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Ian Leonard <antonlacon@gmail.com>
Signed-off-by: Ian Leonard <antonlacon@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a proof of concept of using systemd-sysext and a kodi addon to modify the base image's contents. Systemd-sysxt, in short, is systemd's overlayfs manager that may alter the contents of /usr or /opt. It's intended for making changes to otherwise immutable filesystems. Systemd's intended use case for it is embedded or stateless machines. Read more here:
https://www.freedesktop.org/software/systemd/man/systemd-sysext.html
https://0pointer.net/blog/testing-my-system-code-in-usr-without-modifying-usr.html
https://blogs.igalia.com/berto/2022/09/13/adding-software-to-the-steam-deck-with-systemd-sysext/
The first commit is a systemd mount to back /var/lib/extensions with persistent storage (space in /storage/.config/extensions). I don't write systemd service scripts often, so this may be improved upon.
The demonstration addon is called core-scripts. Once installed, and run, it will put the
update-systemscript into an overlay atop /usr/bin, so it's readily found in $PATH. Systemd-sysext does very minor version control, checking against /etc/os-release'sIDandVERSION_IDvalues match what is in the addon. When the versions don't match, such as a say this addon being tagged for LE11 being present when updating to LE12, systemd-sysext will refuse to load the contents into the overlay. Systemd-sysext does not do finer detail, like 11.0.0 -> 11.0.1 being different. Mitigating this would be to ship the addon already in the image, instead of baking the script in separately (like via busybox's package.mk) and installing the addon later.The goal would be able to replace certain parts of the image via the addon system instead of having to spin a new release image. Candidates could be the settings addon, or a script like is added here.
The addon is barebones, with no user feedback beside content in the log and very little thought given to what does it do when it updates. This will need to be expanded upon if this moves forward.
What would be nice, and I don't know if it's possible with Kodi addons, is to have the addon auto-execute on install or update. As written, the addon needs to be run to effect a change.
I don't know what would happen if two such addons provided
update-system. My expectation is it would be down to a race of which sysext loads faster, or order they're processed (alphabetical?). My expectation is for this to be handled by controlling what addons are added to the tree, rather than trying to make an addon figure it out.Content replaced in the base image via an extension would be writable by an enduser.