migrate sysroot-readonly code here

[cgwalters]

Following on chat from https://lists.fedoraproject.org/archives/list/[email protected]/thread/OPSZ7I4JLFTDC65FPEOUN4CZJNEGKGDS/
I think we should have a mechanism to tell ostree core to turn on the sysroot-ro flag across upgrades.

This would involve taking the linked systemd unit and bash code from https://pagure.io/workstation-ostree-config/blob/main/f/postprocess.sh#_8 and migrating it into either C here (or we could do it in Rust in https://github.com/ostreedev/ostree-rs-ext/ ). I lean a little bit towards the latter, though it creates a new precedent for soft-requiring the Rust code for new "core" ostree features.

We'd need to bikeshed a design (API) for systems to opt-in to enabling this. In a way, really what we're doing is dealing with the fact that we don't have a mechanism for in-place updates to the ostree repository configuration itself.

While I don't want to scope creep this, I could imagine that we have e.g. /usr/lib/ostree/default-repo-config or so?

And perhaps in theory that's how we should have implemented this feature from the start, by looking at a file in the deployment root instead of the repo config.

If we're trying to avoid creating a new general "upgrade the repo config" mechanism, we could invent a "stamp file" approach like /usr/lib/ostree/features/sysroot-ro or so?

[runcom]

so near term, we just package up postprocess.sh for OSes that need that

[travier]

You would want to package the "result" of postprocess.sh, not the script itself.

[runcom]

Yeah, that’s what I meant

[runcom]

my main question is about which package ships the $result of postprocess.sh, assuming that's the short-term solution and this is not blocked on the high level solution Colin sketched in the first comment

[travier]

An ostree sub-package?

[travier]

Short term you can even add them to the ostree dist git until we add them as C/Rust to ostree/ostree-rs-ext

[jlebon]

FYI, this topic came up again recently in an Edge bug. There's a bug in the migration code where if a system upgrades to a version with libostree v2024.6+, it'll have both the migration code and the bootloader naming change. And this breaks the migration code because edit-in-place creates the new BLS entries with the new naming convention and leaves the old BLS entries as well, which sort earlier. Having it upstream and tested in CI likely would've caught this as part of #3206.

On that specific bug, I think the right fix here is to have edit-in-place always reuse the same names that currently exist. Though this is trickier than it sounds: currently OstreeSysroot doesn't keep track of the original filenames that were parsed. It'd either have to be extended to do this or we could just hack this up in ostree_sysroot_deployment_set_kargs_in_place directly to figure it out.

[cgwalters]

Ouch. Yes that analysis sounds right to me.

On that specific bug, I think the right fix here is to have edit-in-place always reuse the same names that currently exist.

I think that makes sense yes, seems quite tractable.

[cgwalters]

One thing that also relates to this is containers/bootc#640