building a qcow2 from a derived image doesn't work throwing Selinux error in the pipeline #168
Comments
|
I think we need to try to minimize whatever is happening in your container build here that's breaking this. We definitely work with derived images - in fact the I think it's one of the packages there, my initial suspect was (Man, testing this is just super annoying with having to push images to a remote registry for each iteration; cc #90 ) |
|
@cgwalters alrighty, I'll try to narrow it down and provide more info (and yeah, super annoying to test and iterate for a bug like this) |
ok, it's |
|
the transaction on the -dev container is this one and flatpak-selinux is there |
|
One thing I do note here is that bootc's self-install does work for this image: Gives me a functioning image. But I don't yet understand what's going wrong with the osbuild bits here. I looked at the filesystem diff from that top layer and it seemed sane-ish (just a policy recompile). |
neat, this is a good way to test it out then for now - I can confirm that I can produce a working image from my kiosk demo using this method (although w/o anaconda, the default target I set in the Containerfile doesn't work but eh, at least it boots correctly) |
|
@achilleas-k following #186 I've narrowed this issue down to just BIB as it just works with bootc self-install as reported above. FROM quay.io/centos-bootc/centos-bootc-dev:stream9
RUN rpm-ostree install gnome-kiosk-script-session && ostree container commitNow, if I self install with bootc I get a working raw image and I'm able to boot it (converting to qcow2 first): $ truncate -s 10G kiosk-base.raw; podman run -ti --pull=newer --rm --privileged --pid=host --security-opt label=type:unconfined_t -v /var/lib/containers:/var/lib/containers -v $PWD:/output quay.io/runcom/kiosk-base:selinux-error bootc install to-disk --via-loopback --skip-fetch-check --generic-image /output/kiosk-base.raw
...
$ qemu-img convert -f raw -O qcow2 kiosk-base.raw kiosk-base.qcow2
$ qemu-system-aarch64 \
-M accel=hvf -device virtio-gpu-pci \
-cpu host \
-smp 2 \
-m 4096 \
-bios /opt/homebrew/Cellar/qemu/8.2.1/share/qemu/edk2-aarch64-code.fd \
-machine virt \
-snapshot kiosk-base.qcow2If I instead use BIB, I get the selinux error: $ cat config.json
{
"blueprint": {
"customizations": {
"user": [
{
"name": "runcom",
"password": "runcom",
"key": "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIL7xFq1HtZKZiaD8MfkhNtn37m8GSc1W168NoSaT9RSf cardno:000F_C36A3FC0",
"groups": [
"wheel"
]
}
]
}
}
}
$ podman run \
--rm \
-it \
--privileged \
--pull=newer \
--security-opt label=type:unconfined_t \
-v $(pwd)/config.json:/config.json \
-v $(pwd)/output:/output \
quay.io/centos-bootc/bootc-image-builder:latest \
--type qcow2 \
--config /config.json \
quay.io/runcom/kiosk-base:selinux-error
...
⏱ Duration: 0s
org.osbuild.ostree.selinux: 28117cb9d06dbd7fe533c7c0bd00b4489b5a67e3d1b06afbde5b1f4531592252 {
"deployment": {
"osname": "default",
"ref": "ostree/1/1/0"
}
}
Traceback (most recent call last):
File "/run/osbuild/bin/org.osbuild.ostree.selinux", line 117, in <module>
r = main(stage_args["tree"],
File "/run/osbuild/bin/org.osbuild.ostree.selinux", line 102, in main
raise ValueError("Could not find SELinux policy")
ValueError: Could not find SELinux policy
⏱ Duration: 0s
Failed
Error: running osbuild failed: exit status 1
2024/02/15 08:19:21 error: running osbuild failed: exit status 1 |
|
I can definitely reproduce this but I'm still not entirely sure what's going on. The ostree.selinux stage should be trying to read |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Building a derived image on osx with podman desktop and trying to create a qcow2 fails with selinux error in the pipeline. Here's the Containerfile used - note it doesn't matter if the non-dev version of the centos-bootc:stream9 container is used, it still fails.
if I just use bib to create a qcow2 from centos-bootc:stream9 or centos-bootc-dev:stream9 it works flawlessy instead
The error I always get is
here's the full pipelines log:
The text was updated successfully, but these errors were encountered: