sysroot: Detect "live" system on /run/ostree-live

[cgwalters]

Support read-only queries, but deny any attempts to make
changes with a clear error.

Now...in the future, we probably do want to support making
"transient" overlays. See:
coreos/fedora-coreos-tracker#354 (comment)

Closes: #1921

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: cgwalters

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [cgwalters]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[cgwalters]

OK, fixed this up and got it to work. No CI here yet, but I did test this manually with an override and cosa buildextend-live.

I've got some thoughts/code in motion for support for testing on "live" systems - it would be most ergonomic with coreos/ignition#935

[jlebon]

I think this needs a rebase too on top of fixed CI.

[rh-atomic-bot]

☔ The latest upstream changes (presumably #2045) made this pull request unmergeable. Please resolve the merge conflicts.

[jlebon]

Sorry for the delay on this. This would definitely be nice to fix!

[jlebon]

2020.4

[jlebon]

I think one important thing worth noting here is that unlike the seemingly similar /run/ostree-booted, this isn't written by OSTree itself. I.e. it's an agreed-upon API between OSTree and OS vendors. Maybe something like:

It is written by external code which drive OSTree in live contexts (e.g. live ISOs or live PXE boots).

?

[jlebon]

Minor: how about prefixing with found /run/ostree-live?

[jlebon]

Hmm OK, so just thinking about this some more and looking at the FCOS side; do we want to think more deeply about what the ideal integration would look like between the OS and libostree?

For example, right now FCOS has to play hacks with the cmdline to fool ostree-prepare-root: https://github.com/coreos/fedora-coreos-config/blob/f49ef1237d6b75f39410147001d14f594daf79cf/overlay.d/05core/usr/lib/dracut/modules.d/20live/ostree-cmdline.sh. Is this how we want things to work long-term?

I'm wondering if we should instead have a ostree=live karg or something that signals ostree-prepare-root to (1) automatically detect the only deployment in /sysroot and prepare root on that, and (2) write the /run/ostree-live stamp file.

/cc @bgilbert

[openshift-ci-robot]

@jlebon: GitHub didn't allow me to request PR reviews from the following users: bgilbert.

Note that only ostreedev members and repo collaborators can review this PR, and authors cannot review their own PRs.

In response to this:

Hmm OK, so just thinking about this some more and looking at the FCOS side; do we want to think more deeply about what the ideal integration would look like between the OS and libostree?

For example, right now FCOS has to play hacks with the cmdline to fool ostree-prepare-root: https://github.com/coreos/fedora-coreos-config/blob/f49ef1237d6b75f39410147001d14f594daf79cf/overlay.d/05core/usr/lib/dracut/modules.d/20live/ostree-cmdline.sh. Is this how we want things to work long-term?

I'm wondering if we should instead have a ostree=live karg or something that signals ostree-prepare-root to (1) automatically detect the only deployment in /sysroot and prepare root on that, and (2) write the /run/ostree-live stamp file.

/cc @bgilbert

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[cgwalters]

I'm wondering if we should instead have a ostree=live karg or something that signals ostree-prepare-root to (1) automatically detect the only deployment in /sysroot and prepare root on that, and (2) write the /run/ostree-live stamp file.

Yeah, that seems reasonable.

I guess there's a much bigger topic around whether it's worth doing the "deployment root" for live systems at all. It might not be really hard to rework things so that libostree supports just not switching root in this case and operating in read-only mode. But OTOH, FCOS already shipped a live system built this way.

[cgwalters]

OTOH live systems don't support in-place updates, so there aren't any backcompat constraints really; we are free to change the API between live systems and libostree.

[cgwalters]

OK in the meantime I split off the prep patch in #2049

[cgwalters]

Gah the rabbit hole here is deep. So today, the FCOS live bits create an overlayfs for /etc. But I just realized that since FCOS also has the readonly sysroot bits on, ostree-remount.service would ordinarily try to set up the bind mount for /etc except it doesn't do that only because ConditionKernelCmdLine=ostree isn't met.

EDIT: Ah but that code already exits early on if / is ro, so I think that's fine.

[openshift-ci-robot]

@cgwalters: PR needs rebase.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[openshift-ci]

@cgwalters: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/sanity	74089e4	link	true	/test sanity
ci/prow/fcos-e2e	74089e4	link	true	/test fcos-e2e
ci/prow/images	74089e4	link	true	/test images

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.