Silverblue unified core: error: Unable to load SELinux policy from /

[travier]

Silverblue/Kinoite/etc. unified core composes are failing in Fedora infra on:

error: Unable to load SELinux policy from /

See:

• https://pagure.io/releng/failed-composes/issue/5188
• https://koji.fedoraproject.org/koji/taskinfo?taskID=103340003
• https://kojipkgs.fedoraproject.org//work/tasks/3/103340003/runroot.log
• https://pagure.io/pungi-fedora/pull-request/1185

This is likely due to selinux-policy-targeted missing from the buildroot. Unified core composes in https://gitlab.com/fedora/ostree/ci-test have been working for a while, with selinux-policy-targeted in the buildroot: https://gitlab.com/fedora/ostree/buildroot/-/blob/main/Containerfile#L26

I'm looking at adding this package to the Fedora buildroot but I'm wondering if we should really require the policy to be available for a build given that we relabel everything at the end if I understood correctly.

Host system details

Fedora build infrastructure.

Expected vs actual behavior

Successful compose even if no SELinux policy is available.

Steps to reproduce it

Build Silverblue in unified core mode in Fedora infra.

Would you like to work on the issue?

Yes, I can do the code change if this is what we agree on.

*Related issues, potential duplicates

• unable to build tree in docker container in fedora 31 #1943
• Error while running inside podman: #2982
• Hard power cycle of centos 7 ostree image typically causes boot to fail with error: failed to load selinux policy #1963

[cgwalters]

I'm looking at adding this package to the Fedora buildroot but I'm wondering if we should really require the policy to be available for a build given that we relabel everything at the end if I understood correctly.

Unified core is about trying to do the same thing for "base image builds" as we do for client side layering.

We do indeed relabel everything at the start, but it's just logically easier to require some policy be present (even if it's not the exact matching version).

Given that the fix is "install a package" which is kind of what Fedora is all about 😄 that sounds not very onerous to me...

So...tentatively closing because I don't think the cost/benefit here is worth it. (But if someone showed up and wanted to hack the rpm-ostree selinux code to handle this case, sure... this also strongly relates to to #971 which is basically the same thing)

[travier]

Indeed, this makes complete sense. Being focused on the server side for this issue, I had forgotten about the client side.

Thanks