This is second time during last 3 months. It happened to me when I was running F32 pre-release variant, I sort of accepted it that time because it was just pre-release distro. But now when F32 is stable, it doesn't sound acceptable that dnf update process takes hours because of this. My update process now hangs on: ... Running scriptlet: selinux-policy-targeted-3.14.5-39.fc32.noarch ... On background: /sbin/restorecon -e /sys -e /proc -e /dev -e /run -e /mnt -e /var/tmp -e /home -e /tmp -e /dev -i -R -f - What causes problems is - I suppose - the '/home' directory (several hundreds of gigabytes, thousands of cloned git repositories with small files, etc.). If anything like that is really expected, we should find a way to inform user that the restorecon needs to be done ... (but automatic start doesn't sound wise to me, it is really hard to predict how long such update will take on large and slow disks).
OK, it wasn't that slow compared to previous F32 pre-release run, now it was "only" 15 minutes. But still.
It is now a known issue, although all the consequences were unexpected till the update to selinux-policy-3.14.5-38.fc32 and did not trigger on testing machines. The inflicting patch was reverted and the downside was announced on the selinux-policy-3.14.5-39.fc32 update: https://bodhi.fedoraproject.org/updates/FEDORA-2020-886cc9af08 The restorecon run on all filesystems should not appear with skipping the update to selinux-policy-3.14.5-38.fc32. The length of the restorecon run certainly depends on the number of files on filesystems. We are not aware of any other previous change leading to global restorecon. One of the previous updates removed a module which should take a few dozens of seconds. *** This bug has been marked as a duplicate of bug 1832327 ***