Dnf upgrade of some packages fail after upgrade from F35

, ,

Could not update flatpak either.

Running transaction
Preparing : 1/1
Running scriptlet: flatpak-1.12.7-1.fc36.x86_64 1/2
Upgrading : flatpak-1.12.7-1.fc36.x86_64 1/2
error: lsetfilecon: (/usr/libexec/flatpak-system-helper;6246dcac, system_u:object_r:flatpak_helper_exec_t:s0) Invalid argument
error: Plugin selinux: hook fsm_file_prepare failed

Error unpacking rpm package flatpak-1.12.7-1.fc36.x86_64
Verifying : flatpak-1.12.7-1.fc36.x86_64 1/2
Verifying : flatpak-1.12.7-1.fc35.x86_64 2/2

1 Like

Please post that info into bugzilla. This is a place to document the issue, not debug it. Thanks.

1 Like

Posted in bugzilla as well.

2 Likes

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.

Posted into bugzilla, a workaround that worked for me was:

sudo semodule -X 200 -r snappy -r container -r flatpak -X 400 -r pcpupstream -r pcpupstream-container -X 100 -r pcp
sudo dnf remove pcp
sudo dnf reinstall -y container-selinux
sudo dnf upgrade

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.

2 Likes

@edwintorok which bugzilla report did you post your workaround in?

Maybe related to Flatpak issue after system-upgrade to F36

My workaround: 2056303 – After upgrade to 36 several packages fail to upgrade to fc36 and 2056303 – After upgrade to 36 several packages fail to upgrade to fc36
Others have posted their workaround on the bug too, the actual list of modules that have to be removed using semodule varies a bit (probably due to what other packages users got installed or not)

1 Like

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:

  1. use grep ^200 instead oif grep -v 100? This would exclude 400 (leaving it alone)
  2. 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 :person_shrugging:.

(Maybe this should be official policy?)

A package update which may fix the issue in bug 2056303 has been submitted to the Fedora updates system.

Stay tuned — it will be available for testing soon!

A candidate fix for this issue has been submitted to the updates-testing repository for testing. If you are experiencing this problem, please help test this update and then report to Bodhi if it solves the problem — or not!

To install this update on your system, run this command: sudo dnf --enablerepo=updates-testing update --advisory=FEDORA-2022-c5bee6b70f

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).

An update has been released to fix this issue.

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.

Please, trying this : Problem update packages in fedora 36 - #2 by ja7ad

1 Like

I tried to create a comprehensive description of this problem in a new topic:

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.

I updated my version with the semodule -r hammer, after guidance from the developer.