Just an update.
The relabeling involved flatpak on my two f35 machines as well as my f34 machine. It also involved grub (/boot/grub2 and below) and /var/lib/boinc on all 3 machines, and /boot + /boot/extlinux on one machine.
I am now ready to check my f36 VM to see if it occurs there as well.
Whatever selinux update was done really should have done the relabel for the user so it did not break booting. By relabeling before I reboot it allows the boot to complete successfully.
The actual semodule command above may depend on what other packages you have installed, I had to add the pcp ones after semodule told me it couldn’t remove it because it was in use by another module (had to keep adding more modules until it was happy, you can find out the module names and priorities with semodule -lfull).
Note that during the removal of pcp it got stuck (pmcd and auditd using 100% CPU), so I had to stop it with systemctl stop pmcd in order for dnf remove pcp to succeed.
I’d like to promote this topic into the main #common-issues category, but I’m not proficient with SELinux enough to judge whether the proposed workarounds are good (e.g. safe for users systems, without side effects) or not. I asked the selinux maintainer to share his views, if possible.
I notice at least one flaw. My system has a custom module I made from audit2allow and added myself. This has priority 400, so would be included with grep -v 100, but isn’t provided by a package. I’m not sure if that needs to be re-installed, but it wouldn’t be with dnf reinstall. So, this should either:
use grep ^200 instead oif grep -v 100? This would exclude 400 (leaving it alone)
use the grep -v 100 and remove anything that has some other priority, and include instructions on putting it back.
I found SELinux/IndependentPolicy - Fedora Project Wiki — but I’m not sure if that’s authoritative. (It notes that it is not official Fedora packaging policy.) Looks like there are examples in the bug with various priorities like 300 and 400 .
I updated the instructions a bit to mention the case of modules not coming from any package.
Of course, such modules can be anything,
so it is impossible to give guidance that always works.
So just say that each case needs to be resolved individually,
but it is possible that they do not have to be touched at all.
The bug has now been marked as a Final blocker,
and there seems to be a fix that does not need user interaction, too.
So perhaps there is no need to have it as a Common Issue anymore?
Your issue seems to be something different than what this entry is supposed to document.
The issue here is that after the upgrade to F36, dnf upgrade fails for SELinux related reasons,
and just relabelling everything does not fix the issue.
There can be other issues related to SELinux, too.
Not all of the should be grouped together.
If it is a highly visible issue and I have time, I generally include even those which are going to be fixed, because it helps people find the issue description and the fix (even if it means just “update your system”).
For this one, I’d promote it immediately if it listed no workarounds and just said “please wait until it’s fixed”. But I don’t feel comfortable including workarounds which I don’t fully understand, e.g. which might have some long-lasting negative effects on the system (like removing selected selinux modules). That’s why I asked the developer for looking at it (but he seems to have little time for this, unfortunately).
A new F35 selinux-policy build. This build should help with F35->F36 upgrade problems.
After you update your system in your usual way (and possibly reboot), you should no longer be affected by this problem. If the problem persists, please start a new discussion topic and we’ll help figure out what’s still wrong.
Because I applied the semodule -r workaround and thus do not have a reproducer for this issue anymore,
and there is now a new proposal for the same issue,
I would like to retract this proposal.
How do I do that?
Regarding the new proposal,
even though I see the point in not listing any risky expert actions as workarounds,
I am bit worried that if the semodule -r workaround is not given,
the listed safer options will not work for everybody,
so that affected users have to resort to reading Bugzilla comments
and end up applying an incomplete version of that workaround.
In particular, almost all “here is how I fixed it” comments in Bugzilla forget to finish off by reinstalling the modules that were removed.
Let’s keep both proposal in place right now. You’re right that I want to include just the safe procedures by default. But if we find people for whom it doesn’t work, I’ll either copy over your instructions, or link to them, or something similar. It would be much easier if I could actually reproduce the bug, but I couldn’t. Sigh.