(In reply to Mars from comment #0)
> #Description of problem:
> 
> Hello! I dont know is this a bug or not. I have some question please:
> Thanks for answers.
> Please do not blame me because Im using nvidia
It's not about blaming, but in case of 3rd party drivers you either need to report the issue for the vendor, or have a workaround.

> 1. Why not fix all file the `fixfiles -F onboot && reboot` command?
Not sure what is the question. Some paths are excluded from relabeling. Some are on a memory filesystem, so relabeling may not be a permanent solution.

> 2. Is this ok? `Warning no default label for /dev/mqueue`
The context is deliberately set to <<none>> as the content needs to be handled by the service which is using it.

> 3. /run/user/* and /run/Network-Manager/ context ok? (Im using built in
> wireguard vpn) 
In this particular case it is a known issue, without a solution yet.

> 4. Why and how can go wrong SELinux contexts? Why would relabel?
Typically when files are moved from a different location, keeping the previous context, but there can be more reasons.

> 
> 
> ## I run following command as root:
> 
> fixfiles -F onboot && reboot
> 
> ## After reboot, I run:
> 
> fixfiles verify
> 
> I see following output:
> 
> Verifying / /boot /dev /dev/hugepages /dev/mqueue /dev/pts /dev/shm /run
> /run/user/1000 /sys /sys/fs/cgroup /sys/fs/pstore /sys/kernel/debug
> /sys/kernel/tracing /tmp
> Would relabel /dev/nvidia-uvm-tools from system_u:object_r:device_t:s0 to
> system_u:object_r:xserver_misc_device_t:s0
> /dev/tty2 not reset as customized by admin to
> unconfined_u:object_r:user_tty_device_t:s0
> Warning no default label for /dev/mqueue
> Would relabel /run/NetworkManager/no-stub-resolv.conf from
> system_u:object_r:NetworkManager_var_run_t:s0 to
> system_u:object_r:net_conf_t:s0
> Would relabel /run/user/1000/keyring from
> unconfined_u:object_r:user_tmp_t:s0 to
> unconfined_u:object_r:gkeyringd_tmp_t:s0
> Would relabel /run/user/1000/keyring/ssh from
> unconfined_u:object_r:user_tmp_t:s0 to
> unconfined_u:object_r:gkeyringd_tmp_t:s0
> Would relabel /run/user/1000/keyring/pkcs11 from
> unconfined_u:object_r:user_tmp_t:s0 to
> unconfined_u:object_r:gkeyringd_tmp_t:s0
> Would relabel /run/user/1000/keyring/control from
> unconfined_u:object_r:user_tmp_t:s0 to
> unconfined_u:object_r:gkeyringd_tmp_t:s0
The service which creates /run/user/1000 probably does not operate 
properly.

> 
> 
> Next time: 
> 
> 1. 
> fixfiles verify /dev/nvidia-uvm-tools 
> Would relabel /dev/nvidia-uvm-tools from system_u:object_r:device_t:s0 to
> system_u:object_r:xserver_misc_device_t:s0
> 
> 2. 
> restorecon /dev/nvidia-uvm-tools
> 
> 3. (No output)
> fixfiles verify /dev/nvidia-uvm-tools
> 
> 
> Is this correct?
We cannot do anything in selinux-policy.

As no new information appeared during the past weeks, we are going to close this bug. If you need to pursue this matter further, feel free to reopen this bug and attach the needed information.