8000 `composefs = maybe` workaround no longer in place · Issue #12 · coreos/rhel-coreos-config · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

composefs = maybe workaround no longer in place #12

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
jlebon opened this issue May 22, 2025 · 4 comments · Fixed by #13
Closed

composefs = maybe workaround no longer in place #12

jlebon opened this issue May 22, 2025 · 4 comments · Fixed by #13
Labels
jira

Comments

@jlebon
Copy link
Member
jlebon commented May 22, 2025

We have

rhel-coreos-config/manifest-el9-shared.yaml

Lines 28 to 34 in 2c3f852

# Set composefs to `maybe` for now because older bootimages
# could be starting with an OSTree that's not new enough.
# https://github.com/openshift/os/issues/1678
if [ -f /usr/lib/ostree/prepare-root.conf ]; then
grep -q 'enabled = true' /usr/lib/ostree/prepare-root.conf
sed -i -e 's,enabled = true,enabled = maybe,' /usr/lib/ostree/prepare-root.conf
fi
to work around openshift/os#1678. But looks like that workaround isn't working correctly in recent builds:

$ podman run --rm -ti quay.io/openshift-release-dev/ocp-v4.0-art-dev:4.19-9.6-node-image cat /usr/lib/ostree/prepare-root.conf
[composefs]
enabled = true
@jlebon jlebon added the jira label May 22, 2025
@dustymabe
Copy link
Member

A snippet from the most recent rhel-9.6 build:

[2025-05-22T19:36:06.953Z] Executing `postprocess` inline script '0'

[2025-05-22T19:36:06.953Z] + '[' -f /usr/lib/ostree/prepare-root.conf ']'

[2025-05-22T19:36:06.953Z] Executing `postprocess` inline script '1'

[2025-05-22T19:36:06.953Z] + cat

[2025-05-22T19:36:06.953Z] Executing `postprocess` inline script '2'

[2025-05-22T19:36:06.953Z] + rm -rf /etc/systemd/system/cryptsetup.target.wants /etc/systemd/system/dbus-org.freedesktop.nm-dispatcher.service /etc/systemd/system/dbus.service '/etc/systemd/system/dev-virtio\x2dports-org.qemu.guest_agent.0.device.wants' /etc/systemd/system/local-fs.target.wants /etc/systemd/system/multi-user.target.wants /etc/systemd/system/network-online.target.wants /etc/systemd/system/sockets.target.wants /etc/systemd/system/sysinit.target.wants /etc/systemd/system/timers.target.wants /etc/systemd/system/vmtoolsd.service.requires

[2025-05-22T19:36:06.953Z] + systemctl preset-all

So the postprocess script is not passing the -f /usr/lib/ostree/prepare-root.conf check?

@dustymabe
Copy link
Member
dustymabe commented May 22, 2025 •
edited
Loading

I think this is a case of postprocess scripts running in an order we didn't expect.

The /usr/lib/ostree/prepare-root.conf is originally created by the postprocess from fedora bootc minimal/ostree.yaml

In coreos-bootc-minimal-plus.yaml we modify /usr/lib/ostree/prepare-root.conf too.

jlebon added a commit to jlebon/rhel-coreos-config that referenced this issue May 22, 2025
@jlebon
manifests: move composefs workaround to common.yaml
3b68e19 
Because of unfortunate and subtle rpm-ostree include semantics, the
postpocess script that flips composefs to `maybe` actually ran before
`prepare-root.conf` was even written (that's done by a postprocess
script in a manifest inherited by minimal-plus).

This will be much clearer once we move to `podman build` because then
all postprocessing scripts from the base layer happen in a different
stage entirely.

Anyway, for now just work around this by moving the composefs workaround
to `common.yaml` directly and checking within it for el9. While we're
here, do a few tweaks:
1. always require `prepare-root.conf` to be there; this would've caught
   this regression
2. strengthen the grep that checks that it turns on composefs
3. add a test that verifies the desired end state (a better test of
   course would be an ugprade test from an old bootimage, though we
   don't have the setup for that currently)

See also coreos/rpm-ostree@7b13723.

Fixes: ca549fe ("Require tier-x")
Fixes: coreos#12
@jlebon jlebon mentioned this issue May 22, 2025
Merged
@jlebon
Copy link
Member Author
jlebon commented May 22, 2025

Yeah, exactly. Fix in #13.

@dustymabe
Copy link
Member

on that front we can't even see if our coreos-bootc-minimal-plus.yaml postprocess is failing:

https://github.com/coreos/fedora-coreos-config/blob/c71d2a33b4343d4ba9626db8ed526dcea30fb64a/manifests/coreos-bootc-minimal-plus.yaml#L26-L42

so let's add a set -x to that postprocess: coreos/fedora-coreos-config#3520

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
jira
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

NO-JIRA: manifests: move composefs workaround to common.yaml jlebon/rhel-coreos-config
2 participants
@dustymabe @jlebon
0