It seems like the new selinux-policy landed at the same time and was tested together with this update? I will try to re-push the update. The worst case scenario is that CI will keep the update blocked.
It seems like the new selinux-policy landed at the same time and was tested together with this update?
No, that's not quite what it means. As it says on the left, that's a "diff_to_last_good" - it's showing you the diff between the openQA settings of the last test that passed before the failure, and those of the failed test. So it's showing you that it just so happens that the most recent pass was a test of an selinux-policy update.
The two were not tested together. openQA does not test pending updates together. How openQA works is that it configures the test system to use the official repositories for the relevant release, then adds a side repository which contains only the packages from the update under test.
For Rawhide update tests, it configures the main 'rawhide' repository and also a repo called 'koji-rawhide' which contains the packages from the current koji buildroot, so it includes packages that have been tagged since the previous nightly compose (I found this gives more reliable results and fewer false failures), so the test system will have all the packages tagged up to around when it started running, give or take, plus the packages from the update being tested. So this test may have included the selinux-policy update if it passed tests and was tagged before the tests for this update ran - I'm not sure, off the top of my head. But it's kinda academic, because again as "diff_to_last_good" implies, the test passed on the selinux-policy update. It also passed for all other updates before and since. It only failed for this update.
My freshly installed Rawhide VM is running in permissive mode by default?
So, when it comes to selinux being in permissive mode by default, I tried again just now -- just to make sure that I wasn't dreaming. I don't know if this is expected or not, but these are my findings:
Fedora-Workstation-Live-osb-Rawhide-20240206.n.0.x86_64.iso -- this has the selinux policy set to permissive right after installation. I was doing the testing on this "osb" version, so maybe that's where I made the mistake?
Fedora-Workstation-Live-x86_64-Rawhide-20240206.n.0.iso -- this one indeed comes with selinux enforcing enabled by default.
This update's test gating status has been changed to 'waiting'.
Ah, I believe that's the experimental image built by osbuild - https://fedoraproject.org/wiki/Changes/FedoraWorkstationImageBuilder . We don't run that one through openQA yet, though we probably should, I just need to get around to implementing it. It's not the "Official" image yet, though. It would be worth reporting...somewhere...that it's not doing the right thing with SELinux, I guess.
For help debugging failed Fedora CI tests (fedora-ci.*), contact the Fedora CI team.
For help debugging failed Fedora CoreOS tests (coreos.*), contact the Fedora CoreOS team.
For help debugging failed openQA tests (update.*), contact the Fedora Quality team, who will usually investigate and diagnose all failures within 24 hours.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'failed'.
This update has been unpushed.
abrtd fails to start on boot because of SELinux denials, it seems:
Yep, I noticed that too. That's why I quickly unpushed the update. I did not see the problem locally though, so I need to investigate more.
Hmm, I cannot reproduce the problem on a freshly installed up-to-date Rawhide VM.
This is interesting:
It seems like the new selinux-policy landed at the same time and was tested together with this update? I will try to re-push the update. The worst case scenario is that CI will keep the update blocked.
msrb edited this update.
msrb edited this update.
This update has been submitted for testing by msrb.
For the record, this is the test bug that I successfully created from the Rawhide VM: https://bugzilla.redhat.com/show_bug.cgi?id=2263025
Oh, wait. My freshly installed Rawhide VM is running in permissive mode by default? That's why I didn't see the problem...
No, that's not quite what it means. As it says on the left, that's a "diff_to_last_good" - it's showing you the diff between the openQA settings of the last test that passed before the failure, and those of the failed test. So it's showing you that it just so happens that the most recent pass was a test of an selinux-policy update.
The two were not tested together. openQA does not test pending updates together. How openQA works is that it configures the test system to use the official repositories for the relevant release, then adds a side repository which contains only the packages from the update under test.
For Rawhide update tests, it configures the main 'rawhide' repository and also a repo called 'koji-rawhide' which contains the packages from the current koji buildroot, so it includes packages that have been tagged since the previous nightly compose (I found this gives more reliable results and fewer false failures), so the test system will have all the packages tagged up to around when it started running, give or take, plus the packages from the update being tested. So this test may have included the selinux-policy update if it passed tests and was tagged before the tests for this update ran - I'm not sure, off the top of my head. But it's kinda academic, because again as "diff_to_last_good" implies, the test passed on the selinux-policy update. It also passed for all other updates before and since. It only failed for this update.
I'm pretty sure that's not the case either. We actually do have a test of that in openQA, and it passed on all recent composes; it's called
base_selinux, you can go to e.g. https://openqa.fedoraproject.org/tests/overview?distri=fedora&version=Rawhide&build=Fedora-Rawhide-20240206.n.0&groupid=1 and search for that string. We run the test on most of the images we test.Thanks for the thorough explanation.
So, when it comes to selinux being in permissive mode by default, I tried again just now -- just to make sure that I wasn't dreaming. I don't know if this is expected or not, but these are my findings:
Fedora-Workstation-Live-osb-Rawhide-20240206.n.0.x86_64.iso -- this has the selinux policy set to permissive right after installation. I was doing the testing on this "osb" version, so maybe that's where I made the mistake?
Fedora-Workstation-Live-x86_64-Rawhide-20240206.n.0.iso -- this one indeed comes with selinux enforcing enabled by default.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'failed'.
This update's test gating status has been changed to 'failed'.
This update's test gating status has been changed to 'failed'.
This update has been obsoleted.
Ah, I believe that's the experimental image built by osbuild - https://fedoraproject.org/wiki/Changes/FedoraWorkstationImageBuilder . We don't run that one through openQA yet, though we probably should, I just need to get around to implementing it. It's not the "Official" image yet, though. It would be worth reporting...somewhere...that it's not doing the right thing with SELinux, I guess.
The new selinux-policy build should address the issue: FEDORA-2024-1ca4c99da3
Just to close the loop here -- I reported the issue with selinux and OSB images to the owners of the Fedora Image Builder change: https://fedoraproject.org/wiki/Changes/FedoraWorkstationImageBuilder
So they are aware of the issue and they will look into it ;)