# LANG=C.UTF8 dnf -y update -x vlc* Last metadata expiration check: 0:13:01 ago on Fri Jun 21 10:15:41 2019. Dependencies resolved. ====================================================================================================================================================================================================== Package Architecture Version Repository Size ====================================================================================================================================================================================================== Upgrading: filesystem x86_64 3.12-1.fc31 koji-builds 1.1 M Transaction Summary ====================================================================================================================================================================================================== Upgrade 1 Package Total size: 1.1 M Downloading Packages: [SKIPPED] filesystem-3.12-1.fc31.x86_64.rpm: Already downloaded Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Running scriptlet: filesystem-3.12-1.fc31.x86_64 1/1 Preparing : 1/1 Upgrading : filesystem-3.12-1.fc31.x86_64 1/2 error: lsetfilecon: (/proc, system_u:object_r:default_t:s0) Operation not supported Cleanup : filesystem-3.11-1.fc31.x86_64 2/2 Running scriptlet: filesystem-3.12-1.fc31.x86_64 2/2 Running scriptlet: filesystem-3.11-1.fc31.x86_64 2/2 Verifying : filesystem-3.12-1.fc31.x86_64 1/2 Verifying : filesystem-3.11-1.fc31.x86_64 2/2 Upgraded: filesystem-3.12-1.fc31.x86_64 Complete! # rpm -qa selinux* selinux-policy-targeted-3.14.4-21.fc31.noarch selinux-policy-3.14.4-21.fc31.noarch [root@cerebro ~]#
Looks like filesystem is attempting to set a file label on /proc, after /proc is mounted would be my guess. chcon system_u:object_r:default_t:s0 /proc chcon: failed to change context of '/proc' to ‘system_u:object_r:default_t:s0’: Operation not supported matchpathcon /proc /proc system_u:object_r:default_t:s0 Which seems wrong.
Hi, Are you able to reproduce it? Thanks, Lukas.
that's a dnf update trace, so it needs to wait for the next filesystem update before it can be tested forcing a reinstall messes up all the scriplet sequencing :(
*** Bug 1726018 has been marked as a duplicate of this bug. ***
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to '31'.
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to 31.
Upgrading : grub2-common-1:2.04-2.fc32.noarch 2/904 error: lsetfilecon: (/boot/efi/EFI/fedora, system_u:object_r:boot_t:s0) Operation not supported Upgrading : grub2-efi-x64-1:2.04-2.fc32.x86_64 405/904 error: lsetfilecon: (/boot/efi/EFI/fedora/fonts, system_u:object_r:boot_t:s0) Operation not supported error: lsetfilecon: (/boot/efi/EFI/fedora/grubx64.efi;5d9f1c51, system_u:object_r:boot_t:s0) Operation not supported
Just now while running "sudo dnf -y update" on a F31 beta install to final. Upgrading : grub2-common-1:2.02-100.fc31.noarch 3/1254 error: lsetfilecon: (/boot/efi/EFI/fedora, system_u:object_r:boot_t:s0) Operation not supported ... error: lsetfilecon: (/boot/efi/EFI/fedora/fonts, system_u:object_r:boot_t:s0) Operation not supported error: lsetfilecon: (/boot/efi/EFI/fedora/grubia32.efi;5dac3d37, system_u:object_r:boot_t:s0) Operation not supported Upgrading : grub2-efi-x64-1:2.02-100.fc31.x86_64 570/1254 error: lsetfilecon: (/boot/efi/EFI/fedora/grubx64.efi;5dac3d37, system_u:object_r:boot_t:s0) Operation not supported ... error: lsetfilecon: (/boot/efi/EFI/fedora/fonts, system_u:object_r:boot_t:s0) Operation not supported error: lsetfilecon: (/boot/efi/EFI/fedora/grubia32.efi;5dac3d37, system_u:object_r:boot_t:s0) Operation not supported Upgrading : grub2-efi-x64-1:2.02-100.fc31.x86_64 570/1254 error: lsetfilecon: (/boot/efi/EFI/fedora/grubx64.efi;5dac3d37, system_u:object_r:boot_t:s0) Operation not supported
/boot/efi is a vFAT filesystem which does not supported the extended attributes needed to store an SELinux label. dnf (or rpm or selinux-policy) should not be trying to set a label on these files.
Moving to filesystem component. We should not try to relabel /proc directory (even in SELinux policy /proc is not defined as proc_t).
Filesystem calls "restorecon /proc 2>/dev/null >/dev/null || :" . It is called as %pretrans scriptlet, as some dirs - (/proc, /sys) are created by other packages and some dirs had wrong contexts in some types of installation. I don't fully understand why error message is shown when I drop stderr and stdout intentionally to prevent such messages. It was done to fix https://bugzilla.redhat.com/show_bug.cgi?id=1034922 - which caused more serious issues than harmless error message from ENOTSUPP. Do you have any good suggestion how to fix the issue from this bz without restoring context on /proc and other system dirs?
Ondrej, Do you have some tests to test possible scratch build removing relabeling /proc? This change was introduced several years ago, maybe it's time to review it again. Thanks, Lukas.
Hello, ever since I upgraded to F31 (even clean install), the hidden grub feature seems to be broken due this bug. I tried reinstalling grub and shim but I get the following. ~$ sudo dnf reinstall grub2-efi shim Last metadata expiration check: 2:20:06 ago on Sun Nov 24 12:42:14 2019. Dependencies resolved. ====================================================================================================================== Package Architecture Version Repository Size ====================================================================================================================== Reinstalling: grub2-efi-x64 x86_64 1:2.02-100.fc31 fedora 458 k shim-x64 x86_64 15-8 fedora 658 k Transaction Summary ====================================================================================================================== Total download size: 1.1 M Installed size: 8.2 M Is this ok [y/N]: y Downloading Packages: (1/2): shim-x64-15-8.x86_64.rpm 568 kB/s | 658 kB 00:01 (2/2): grub2-efi-x64-2.02-100.fc31.x86_64.rpm 380 kB/s | 458 kB 00:01 ---------------------------------------------------------------------------------------------------------------------- Total 503 kB/s | 1.1 MB 00:02 Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Preparing : 1/1 Reinstalling : shim-x64-15-8.x86_64 1/4 error: lsetfilecon: (/boot/efi/EFI/BOOT/BOOTX64.EFI;5ddae1d7, system_u:object_r:boot_t:s0) Operation not supported error: lsetfilecon: (/boot/efi/EFI/BOOT/fbx64.efi;5ddae1d7, system_u:object_r:boot_t:s0) Operation not supported error: lsetfilecon: (/boot/efi/EFI/fedora/BOOTX64.CSV;5ddae1d7, system_u:object_r:boot_t:s0) Operation not supported error: lsetfilecon: (/boot/efi/EFI/fedora/mmx64.efi;5ddae1d7, system_u:object_r:boot_t:s0) Operation not supported error: lsetfilecon: (/boot/efi/EFI/fedora/shim.efi;5ddae1d7, system_u:object_r:boot_t:s0) Operation not supported error: lsetfilecon: (/boot/efi/EFI/fedora/shimx64-fedora.efi;5ddae1d7, system_u:object_r:boot_t:s0) Operation not supported error: lsetfilecon: (/boot/efi/EFI/fedora/shimx64.efi;5ddae1d7, system_u:object_r:boot_t:s0) Operation not supported Reinstalling : grub2-efi-x64-1:2.02-100.fc31.x86_64 2/4 error: lsetfilecon: (/boot/efi/EFI/fedora/fonts, system_u:object_r:boot_t:s0) Operation not supported error: lsetfilecon: (/boot/efi/EFI/fedora/grubx64.efi;5ddae1d7, system_u:object_r:boot_t:s0) Operation not supported Cleanup : shim-x64-15-8.x86_64 3/4 Cleanup : grub2-efi-x64-1:2.02-100.fc31.x86_64 4/4 Verifying : grub2-efi-x64-1:2.02-100.fc31.x86_64 1/4 Verifying : grub2-efi-x64-1:2.02-100.fc31.x86_64 2/4 Verifying : shim-x64-15-8.x86_64 3/4 Verifying : shim-x64-15-8.x86_64 4/4 Reinstalled: grub2-efi-x64-1:2.02-100.fc31.x86_64 shim-x64-15-8.x86_64 Complete! Sorry if it is redundant information, but I wanted to be sure it's the same bug.
*** Bug 1777237 has been marked as a duplicate of this bug. ***
Since this affects grub2 as well, this looks to be a regression in restorecon or some generic rpm scriptlet macro. Lukas, shouldn't restorecon avoid setting labels where they can't be set? Why do the errors suddenly show up for different packages?
Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
This bug was accidentally closed due to a query error. Reopening.
Running sudo dnf update resulted in the following errors appearing in the log Upgrading : grub2-common-1:2.02-103.fc31.noarch 1/164 error: lsetfilecon: (/boot/efi/EFI/fedora, system_u:object_r:boot_t:s0) Operation not supported ... Upgrading : grub2-efi-ia32-1:2.02-103.fc31.x86_64 52/164 error: lsetfilecon: (/boot/efi/EFI/fedora/fonts, system_u:object_r:boot_t:s0) Operation not supported error: lsetfilecon: (/boot/efi/EFI/fedora/grubia32.efi;5de0c50e, system_u:object_r:boot_t:s0) Operation not supported Upgrading : grub2-efi-x64-1:2.02-103.fc31.x86_64 53/164 error: lsetfilecon: (/boot/efi/EFI/fedora/grubx64.efi;5de0c50e, system_u:object_r:boot_t:s0) Operation not supported ... Upgrading : grub2-efi-ia32-cdboot-1:2.02-103.fc31.x86_64 74/164 error: lsetfilecon: (/boot/efi/EFI/fedora/fonts, system_u:object_r:boot_t:s0) Operation not supported error: lsetfilecon: (/boot/efi/EFI/fedora/fonts/unicode.pf2;5de0c50e, system_u:object_r:boot_t:s0) Operation not supported error: lsetfilecon: (/boot/efi/EFI/fedora/gcdia32.efi;5de0c50e, system_u:object_r:boot_t:s0) Operation not supported Upgrading : grub2-efi-x64-cdboot-1:2.02-103.fc31.x86_64 75/164 error: lsetfilecon: (/boot/efi/EFI/fedora/gcdx64.efi;5de0c50e, system_u:object_r:boot_t:s0) Operation not supported ...
I also got this error: /v/log cat dnf.rpm.log | grep Operation 2019-12-03T16:32:28Z INFO error: lsetfilecon: (/boot/efi/EFI/fedora, system_u:object_r:boot_t:s0) Operation not supported 2019-12-03T16:34:42Z INFO error: lsetfilecon: (/boot/efi/EFI/fedora/fonts, system_u:object_r:boot_t:s0) Operation not supported error: lsetfilecon: (/boot/efi/EFI/fedora/grubx64.efi;5de68e15, system_u:object_r:boot_t:s0) Operation not supported 2019-12-13T09:15:57Z INFO error: lsetfilecon: (/boot/efi/EFI/fedora, system_u:object_r:boot_t:s0) Operation not supported 2019-12-13T09:21:10Z INFO error: lsetfilecon: (/boot/efi/EFI/fedora/fonts, system_u:object_r:boot_t:s0) Operation not supported error: lsetfilecon: (/boot/efi/EFI/fedora/grubx64.efi;5df356b3, system_u:object_r:boot_t:s0) Operation not supported
*** Bug 1778389 has been marked as a duplicate of this bug. ***
*** Bug 1792803 has been marked as a duplicate of this bug. ***
*** Bug 1785986 has been marked as a duplicate of this bug. ***
I will drop the restorecon for /proc as suggested by Lukas, for grub2, someone probably should file separate bugzilla - as I can't fix that one as part of the filesystem update.
*** Bug 1740234 has been marked as a duplicate of this bug. ***
Hi all, in my case, kernel updating doesn't rebuild grub.cfg, and the system cannot restart on the last kernel! To resolve this, I have to manually run the command line: # grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg selinux is set to permissive: $ sestatus SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: permissive Mode from config file: permissive Policy MLS status: enabled Policy deny_unknown status: allowed Memory protection checking: actual (secure) Max kernel policy version: 31 $ I try to reinstall grub2-efi to solve it, but nothing changes. # dnf reinstall grub2-efi Dernière vérification de l’expiration des métadonnées effectuée il y a 3:01:00 le lun. 03 févr. 2020 16:10:10 CET. Dépendances résolues. ================================================================================ Paquet Architecture Version Dépôt Taille ================================================================================ Réinstallation: grub2-efi-x64 x86_64 1:2.02-105.fc31 updates 458 k Résumé de la transaction ================================================================================ Taille totale des téléchargements : 458 k Taille des paquets installés : 2.2 M Voulez-vous continuer ? [o/N] : o Téléchargement des paquets : grub2-efi-x64-2.02-105.fc31.x86_64.rpm 222 kB/s | 458 kB 00:02 -------------------------------------------------------------------------------- Total 162 kB/s | 458 kB 00:02 Test de la transaction La vérification de la transaction a réussi. Lancement de la transaction de test Transaction de test réussie. Exécution de la transaction Préparation : 1/1 Réinstallation : grub2-efi-x64-1:2.02-105.fc31.x86_64 1/2 erreur : lsetfilecon: (/boot/efi/EFI/fedora/fonts, system_u:object_r:boot_t:s0) Opération non supportée erreur : lsetfilecon: (/boot/efi/EFI/fedora/grubx64.efi;5e386251, system_u:object_r:boot_t:s0) Opération non supportée Nettoyage de : grub2-efi-x64-1:2.02-105.fc31.x86_64 2/2 Vérification de : grub2-efi-x64-1:2.02-105.fc31.x86_64 1/2 Vérification de : grub2-efi-x64-1:2.02-105.fc31.x86_64 2/2 Réinstallé: grub2-efi-x64-1:2.02-105.fc31.x86_64 Terminé ! # Maybe these errors explain my problem. Sorry for my English. Regards.
Alexandre, I suspect you are running into a different problem since I see you are running SELinux in Permissive mode. Permissive mode logs errors, but does not actually block any actions. It sounds like your grub configuration is a mixture of the legacy, monolithic grub config, and the new BootLoaderSpec (BLS) config. With BLS, the grub.cfg no longer gets updated. Instead, each kernel creates a conf file in /boot/loader/entries/, and grub reads the *.conf files to dynamically build a menu during boot. This is why the grub.cfg file is not updated when installing a new kernel. More info: https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault https://systemd.io/BOOT_LOADER_SPECIFICATION/
Hi Jeff, I changed GRUB_ENABLE_BLSCFG=false to GRUB_ENABLE_BLSCFG=true on my /etc/default/grub then I run # grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg. I wait for the new kernel update. Thanks for your help. Alexandre
It works ! After the kernel update today, the system reboot on the last kernel 5.4.18-200.fc31.x86_64. That's good ! I shall set selinux to strict.
*** Bug 1801213 has been marked as a duplicate of this bug. ***
*** Bug 1798378 has been marked as a duplicate of this bug. ***
Is bug 1822884 a duplicate of this one?
*** Bug 1822884 has been marked as a duplicate of this bug. ***
*** Bug 1823000 has been marked as a duplicate of this bug. ***
Noting that this is a closed bug for rawhide, and the setting permissions on a FAT file is, in fact, not supported, I'd just like to remark that my most recent upgrade to kernel-5.6.6-200.fc31, and grub2 1:2.02-108, caused this error message to be displayed. Since, as far as I can see, not having SE context set on a link in the EFI VFAT file would be of no consequence, I'd suggest that the messaged by suppressed when the file system does not, in fact, support the proposed operation.
Indeed, this just resurfaced: Upgrading : grub2-efi-ia32-1:2.02-108.fc31.x86_64 75/203 error: lsetfilecon: (/boot/efi/EFI/fedora/fonts, system_u:object_r:boot_t:s0) Operation not supported error: lsetfilecon: (/boot/efi/EFI/fedora/grubia32.efi;5ea6438e, system_u:object_r:boot_t:s0) Operation not supported $ sudo ls -1dZ /boot/efi/EFI/fedora/{fonts,grubia32.efi} system_u:object_r:dosfs_t:s0 /boot/efi/EFI/fedora/fonts system_u:object_r:dosfs_t:s0 /boot/efi/EFI/fedora/grubia32.efi $ mount | grep /boot/efi /dev/nvme0n1p1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=winnt,errors=remount-ro) Can this bug be re-opened again or should we open a new report?
Again same comment while upgrading grub2 with dnf in Fedora 32 bete. the bug is still with us. Open it again.
> uname -isrvop Linux 5.6.6-200.fc31.x86_64 #1 SMP Tue Apr 21 15:34:22 UTC 2020 x86_64 x86_64 GNU/Linux What I did: sudo dnf update in /var/log > grep -R lsetfilecon *dnf* ... dnf.rpm.log:2020-04-27T10:12:18Z INFO error: lsetfilecon: (/boot/efi/EFI/fedora, system_u:object_r:boot_t:s0) Operation not supported dnf.rpm.log:2020-04-27T10:14:29Z INFO error: lsetfilecon: (/boot/efi/EFI/fedora/fonts, system_u:object_r:boot_t:s0) Operation not supported dnf.rpm.log:error: lsetfilecon: (/boot/efi/EFI/fedora/grubx64.efi;5ea6b000, system_u:object_r:boot_t:s0) Operation not supported If you need further information let me know.
Is this bug properly set to a filesystem problem? It seems to me that the SELinux system should, as a general rule, not be trying to set permission on items in file system (like FAT) that have no permissions support. (And, does FAT even support links? That system is quite old, and, I suspect, predates any "link" concept. Did MS retrofit it with links?)
I also confirm this bug still exists, however in a somewhat different scenario. Today I've run dnf update on F31, installing new 5.6.6 kernel, and ever since I experience massive problems with grub - It doesn't detect Linux entries anymore! What's even stranger, is that it perfectly detects the Windows partition (I'm on a dual boot). Fortunately - It seems grub actually does see Linux entries when it matters most - at boot time. I tried disabling & enabling BLS_CFG, but with no luck. Searching for a solution to this problem, I came here after attempting to reinstall grub2 packages, encountering errors very similar to this: > lsetfilecon: (/boot/efi/EFI/fedora, system_u:object_r:boot_t:s0) Operation not supported
Created attachment 1682633 [details] dnf output showing the error I just had this error happen on fedora 32 beta (with the dnf upgrade taking me to the release version of f32). Attachment contains the output of dnf. Some snippets from the full output: error: lsetfilecon: (/boot/efi/EFI/fedora, system_u:object_r:boot_t:s0) Operation not supported ... error: lsetfilecon: (/boot/efi/EFI/fedora/fonts, system_u:object_r:boot_t:s0) Operation not supported error: lsetfilecon: (/boot/efi/EFI/fedora/grubia32.efi;5ea898fe, system_u:object_r:boot_t:s0) Operation not supported Upgrading : grub2-efi-x64-1:2.04-14.fc32.x86_64 109/304 error: lsetfilecon: (/boot/efi/EFI/fedora/grubx64.efi;5ea898fe, system_u:object_r:boot_t:s0) Operation not supported ... error: lsetfilecon: (/boot/efi/EFI/fedora/fonts, system_u:object_r:boot_t:s0) Operation not supported error: lsetfilecon: (/boot/efi/EFI/fedora/fonts/unicode.pf2;5ea898fe, system_u:object_r:boot_t:s0) Operation not supported error: lsetfilecon: (/boot/efi/EFI/fedora/gcdia32.efi;5ea898fe, system_u:object_r:boot_t:s0) Operation not supported Upgrading : grub2-efi-x64-cdboot-1:2.04-14.fc32.x86_64 122/304 error: lsetfilecon: (/boot/efi/EFI/fedora/gcdx64.efi;5ea898fe, system_u:object_r:boot_t:s0) Operation not supported
The bug is not fixed: # rpm -q filesystem filesystem-3.14-2.fc32.x86_64 # rpm -Uhv filesystem-3.14-2.fc32.x86_64.rpm --force Verifying... ################################# [100%] Preparing... ################################# [100%] Updating / installing... 1:filesystem-3.14-2.fc32 error: lsetfilecon: (/proc, system_u:object_r:default_t:s0) Operation not supported ################################# [ 50%] Cleaning up / removing... 2:filesystem-3.14-2.fc32 ################################# [100%] The problem not in explicit call of restorecon but in rpm which calls lgetxattr() for each entry in %files.
Ok, so from a users perspective the error messages for /boot/efi can be ignored? Setting no context for FAT or other systems that do not support extended attributes seems to make sense, but I am not sure this IS the wanted solution. An alternative could be: https://docs.fedoraproject.org/en-US/Fedora/13/html-single/Security-Enhanced_Linux/index.html#sect-Security-Enhanced_Linux-Working_with_SELinux-Mounting_File_Systems ???
https://github.com/rpm-software-management/rpm/pull/976
(In reply to Daniel Bisar from comment #44) > Ok, so from a users perspective the error messages for /boot/efi can be > ignored? > Setting no context for FAT or other systems that do not support extended > attributes seems to make sense, but I am not sure this IS the wanted > solution. An alternative could be: > > https://docs.fedoraproject.org/en-US/Fedora/13/html-single/Security- > Enhanced_Linux/index.html#sect-Security-Enhanced_Linux-Working_with_SELinux- > Mounting_File_Systems > > ??? Yes, they're harmless. See https://github.com/rpm-software-management/rpm/pull/976
*** Bug 1819817 has been marked as a duplicate of this bug. ***
FEDORA-2020-feefa460b1 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-feefa460b1
Ladies and gentlemen, sorry for stupid question but this bug popped up somewhere in F31 times, so maybe there is a chance to find what update caused it and roll things back? If the rollback is not possible due to some reasons, can any of experts please put down pros and contras of both solutions discussed above? I would go for the second but I am definitely not that knowledgeable person to see all the consequences: 1. Setting no context to all FS that do not support extended attributes 2. Assigning single (default) context as explained here: https://docs.fedoraproject.org/en-US/Fedora/13/html-single/Security-Enhanced_Linux/index.html#sect-Security-Enhanced_Linux-Working_with_SELinux-Mounting_File_Systems
For whatever reason Bodhi failed to add a note about the F31 update: https://bodhi.fedoraproject.org/updates/FEDORA-2020-feefa460b1
(In reply to Panu Matilainen from comment #50) > For whatever reason Bodhi failed to add a note about the F31 update: > https://bodhi.fedoraproject.org/updates/FEDORA-2020-feefa460b1 It's there in c#48
Oh, right, sorry. So what's missing is the F32 update, which is even stranger as that's the first one filed. Anyway, this is the actually missing link: https://bodhi.fedoraproject.org/updates/FEDORA-2020-54205e879b
FEDORA-2020-feefa460b1 has been pushed to the Fedora 31 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-feefa460b1` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-feefa460b1 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-feefa460b1 has been pushed to the Fedora 31 stable repository. If problem still persists, please make note of it in this bug report.
This bug still exist for Rawhide (Fedora33)
This bug still exist for Rawhide (Fedora33) , so could you please reopen this ticket
Um. The fix backported to F32 and F31 has been in rpm 4.16 (alpha) all along.
Is this the same as I have error in update error: Checkout filesystem-3.14-2.fc32.x86_64: opendir(local): No such file or directory in silverblue 33?
After repeatedly getting this error, here's what worked for me to rebase to Rawhide Silverblue on x86_64 from F32 Silverblue: 1. Reset, removing all installed overlays then reboot: rpm-ostree reset --overlays --reboot 2. Rebase to Rawhide Silverblue then reboot: rpm-ostree --branch=fedora:fedora/rawhide/ppc64le/silverblue --reboot 3. Install all your overlays then reboot: rpm-ostree --install <image-pollution-pkg0.rpm [image-pollution-pkg1.rpm]> --reboot
After repeatedly getting this error, here's what worked for me to rebase to Rawhide Silverblue on x86_64 from F32 Silverblue: 1. Reset, removing all installed overlays then reboot: rpm-ostree reset --overlays --reboot 2. Rebase to Rawhide Silverblue then reboot: rpm-ostree rebase --branch=fedora:fedora/rawhide/ppc64le/silverblue --reboot 3. Install all your overlays then reboot: rpm-ostree install <image-pollution-pkg0.rpm [image-pollution-pkg1.rpm]> --reboot
This ticket is closed but I can't find any actual solution listed. I am seeing the same error on RHEL8 when installing the current latest updates): Upgrading : grub2-common-1:2.02-87.el8_2.noarch 2/131 error: lsetfilecon: (/boot/efi/EFI/redhat, system_u:object_r:boot_t:s0) Operation not supported Upgrading : grub2-efi-x64-1:2.02-87.el8_2.x86_64 58/131 error: lsetfilecon: (/boot/efi/EFI/redhat/fonts, system_u:object_r:boot_t:s0) Operation not supported error: lsetfilecon: (/boot/efi/EFI/redhat/grubx64.efi;5f2405cb, system_u:object_r:boot_t:s0) Operation not supported Upgrading : shim-x64-15-14.el8_2.x86_64 65/131 error: lsetfilecon: (/boot/efi/EFI/BOOT/BOOTX64.EFI;5f2405cb, system_u:object_r:boot_t:s0) Operation not supported error: lsetfilecon: (/boot/efi/EFI/BOOT/fbx64.efi;5f2405cb, system_u:object_r:boot_t:s0) Operation not supported error: lsetfilecon: (/boot/efi/EFI/redhat/BOOTX64.CSV;5f2405cb, system_u:object_r:boot_t:s0) Operation not supported error: lsetfilecon: (/boot/efi/EFI/redhat/mmx64.efi;5f2405cb, system_u:object_r:boot_t:s0) Operation not supported error: lsetfilecon: (/boot/efi/EFI/redhat/shimx64-redhat.efi;5f2405cb, system_u:object_r:boot_t:s0) Operation not supported error: lsetfilecon: (/boot/efi/EFI/redhat/shimx64.efi;5f2405cb, system_u:object_r:boot_t:s0) Operation not supported Is there a fix? If so will it be released for RHEL8 as well?
Same here on CentOS 8: Upgrading : grub2-common-1:2.02-87.el8_2.noarch 1/28 error: lsetfilecon: (/boot/efi/EFI/centos, system_u:object_r:boot_t:s0) Operation not supported Upgrading : grub2-efi-x64-1:2.02-87.el8_2.x86_64 12/28 error: lsetfilecon: (/boot/efi/EFI/centos/fonts, system_u:object_r:boot_t:s0) Operation not supported error: lsetfilecon: (/boot/efi/EFI/centos/grubx64.efi;5f256e11, system_u:object_r:boot_t:s0) Operation not supported Upgrading : shim-x64-15-13.el8.x86_64 14/28 error: lsetfilecon: (/boot/efi/EFI/BOOT/BOOTX64.EFI;5f256e11, system_u:object_r:boot_t:s0) Operation not supported error: lsetfilecon: (/boot/efi/EFI/BOOT/fbx64.efi;5f256e11, system_u:object_r:boot_t:s0) Operation not supported error: lsetfilecon: (/boot/efi/EFI/centos/BOOTX64.CSV;5f256e11, system_u:object_r:boot_t:s0) Operation not supported error: lsetfilecon: (/boot/efi/EFI/centos/mmx64.efi;5f256e11, system_u:object_r:boot_t:s0) Operation not supported error: lsetfilecon: (/boot/efi/EFI/centos/shimx64-centos.efi;5f256e11, system_u:object_r:boot_t:s0) Operation not supported error: lsetfilecon: (/boot/efi/EFI/centos/shimx64.efi;5f256e11, system_u:object_r:boot_t:s0) Operation not supported This happens to be a VM built/running on host SSD storage: # more /etc/fstab UUID=9c55256b-8f4a-4c48-954f-5a0a22eeb40a / xfs defaults 0 0 UUID=c67db3b0-2be8-4020-abce-9c00efd90213 /boot ext4 defaults 1 2 UUID=E3F4-78AC /boot/efi vfat umask=0077,shortname=winnt 0 2 UUID=2141a637-c6de-4e78-8c23-06515a95bda0 /home xfs defaults 0 0 UUID=b452483d-d4b0-4d1b-b8bf-57624d2ee0a9 /sql xfs defaults 0 0 UUID=199c9fee-c388-46f1-9606-8a4ac34dcf48 swap swap defaults 0 0
This is a *Fedora* bug. What happens (or not) in RHEL, CentOS or some other arbitrary distro is not relevant to this bug.
Totally understand that, Panu, but wonder two things: 1. Thinking it might help someone else with debugging, is information sharing discouraged? 2. What domain is your E-mail address hosted from?