TPM Does Not Work Virt-Manager Fedora 40

Ask Fedora
, , , , , ,
1

Hello everyone!

For context, I have a computer that was running Fedora 39 and I recently upgraded to Fedora 40.

There appears to be an issue with Virt-Manager / libvirt in Fedora 40. SELinux is preventing me from creating a new guest image if I try to emulate a TPM 2.0. Digging into it, I eventually find a log file that reports “swtpm at /usr/bin/swtpm does not support TPM 2” and there will be exceptions in SELinux indicating that it blocked stuff.

If I disable SELinux I have no issues, I can create the guest, suggesting the issue is with SELinux.

I tried doing a “touch /.autorelabel” and rebooting the system as I found other posts suggesting that the context labels were wrong after the upgrade but this did not correct the issue for me. Just for clarification, I don’t have an issue with running guest VMs, I only have an issue if the guest VM is emulating a TPM.

Running “ausearch -m AVC,USER_AVC -ts recent” I get entries that look like this:

time->Thu Apr 25 18:01:14 2024
type=AVC msg=audit(1714093274.173:279): avc:  denied  { relabelfrom } for  pid=6652 comm="rpc-virtqemud" name="1-fedora39-40-TPM-Upg" dev="tmpfs" ino=2915 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:virt_var_run_t:s0 tclass=dir permissive=1
----
time->Thu Apr 25 18:01:14 2024
type=AVC msg=audit(1714093274.226:281): avc:  denied  { add_name } for  pid=6422 comm="rpc-virtqemud" name="fedora39-40-TPM-Upg-swtpm.log" scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=dir permissive=1
----
time->Thu Apr 25 18:01:14 2024
type=AVC msg=audit(1714093274.226:282): avc:  denied  { create } for  pid=6422 comm="rpc-virtqemud" name="fedora39-40-TPM-Upg-swtpm.log" scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=file permissive=1
----
time->Thu Apr 25 18:01:14 2024
type=AVC msg=audit(1714093274.226:283): avc:  denied  { write } for  pid=6422 comm="rpc-virtqemud" path="/var/log/swtpm/libvirt/qemu/fedora39-40-TPM-Upg-swtpm.log" dev="dm-0" ino=878537 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=file permissive=1
----
time->Thu Apr 25 18:01:14 2024
type=AVC msg=audit(1714093274.226:284): avc:  denied  { setattr } for  pid=6422 comm="rpc-virtqemud" name="fedora39-40-TPM-Upg-swtpm.log" dev="dm-0" ino=878537 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=file permissive=1
----
time->Thu Apr 25 18:01:14 2024
type=AVC msg=audit(1714093274.272:286): avc:  denied  { getattr } for  pid=6422 comm="rpc-virtqemud" name="/" dev="dm-0" ino=256 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:fs_t:s0 tclass=filesystem permissive=1
----
time->Thu Apr 25 18:01:14 2024
type=AVC msg=audit(1714093274.283:287): avc:  denied  { open } for  pid=6659 comm="swtpm" path="/var/log/swtpm/libvirt/qemu/fedora39-40-TPM-Upg-swtpm.log" dev="dm-0" ino=878537 scontext=system_u:system_r:swtpm_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=file permissive=0
----

Running “sealert -l “*”” I get the following output:

SELinux is preventing rpc-virtqemud from relabelfrom access on the directory 2-fedora39-TPM.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that rpc-virtqemud should be allowed relabelfrom access on the 2-fedora39-TPM directory by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'rpc-virtqemud' --raw | audit2allow -M my-rpcvirtqemud
# semodule -X 300 -i my-rpcvirtqemud.pp


Additional Information:
Source Context                system_u:system_r:virtqemud_t:s0
Target Context                system_u:object_r:virt_var_run_t:s0
Target Objects                2-fedora39-TPM [ dir ]
Source                        rpc-virtqemud
Source Path                   rpc-virtqemud
Port                          <Unknown>
Host                          bartlebyvi
Source RPM Packages           
Target RPM Packages           
SELinux Policy RPM            selinux-policy-targeted-40.16-1.fc40.noarch
Local Policy RPM              selinux-policy-targeted-40.16-1.fc40.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     bartlebyvi
Platform                      Linux bartlebyvi 6.8.7-300.fc40.x86_64 #1 SMP
                              PREEMPT_DYNAMIC Wed Apr 17 19:21:08 UTC 2024
                              x86_64
Alert Count                   1
First Seen                    2024-04-25 19:25:29 PDT
Last Seen                     2024-04-25 19:25:29 PDT
Local ID                      f0329c26-325e-4097-a2b2-331d53c6cc3d

Raw Audit Messages
type=AVC msg=audit(1714098329.840:387): avc:  denied  { relabelfrom } for  pid=7646 comm="rpc-virtqemud" name="2-fedora39-TPM" dev="tmpfs" ino=3634 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:virt_var_run_t:s0 tclass=dir permissive=1


Hash: rpc-virtqemud,virtqemud_t,virt_var_run_t,dir,relabelfrom

SELinux is preventing rpc-virtqemud from setattr access on the file fedora39-TPM-swtpm.log.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that rpc-virtqemud should be allowed setattr access on the fedora39-TPM-swtpm.log file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'rpc-virtqemud' --raw | audit2allow -M my-rpcvirtqemud
# semodule -X 300 -i my-rpcvirtqemud.pp


Additional Information:
Source Context                system_u:system_r:virtqemud_t:s0
Target Context                system_u:object_r:var_log_t:s0
Target Objects                fedora39-TPM-swtpm.log [ file ]
Source                        rpc-virtqemud
Source Path                   rpc-virtqemud
Port                          <Unknown>
Host                          bartlebyvi
Source RPM Packages           
Target RPM Packages           
SELinux Policy RPM            selinux-policy-targeted-40.16-1.fc40.noarch
Local Policy RPM              selinux-policy-targeted-40.16-1.fc40.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     bartlebyvi
Platform                      Linux bartlebyvi 6.8.7-300.fc40.x86_64 #1 SMP
                              PREEMPT_DYNAMIC Wed Apr 17 19:21:08 UTC 2024
                              x86_64
Alert Count                   1
First Seen                    2024-04-25 19:25:29 PDT
Last Seen                     2024-04-25 19:25:29 PDT
Local ID                      1449b9d7-ec71-4985-aea0-57193d9e38ae

Raw Audit Messages
type=AVC msg=audit(1714098329.851:388): avc:  denied  { setattr } for  pid=3334 comm="rpc-virtqemud" name="fedora39-TPM-swtpm.log" dev="dm-0" ino=537436 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=file permissive=1


Hash: rpc-virtqemud,virtqemud_t,var_log_t,file,setattr

SELinux is preventing rpc-virtqemud from getattr access on the filesystem /.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that rpc-virtqemud should be allowed getattr access on the  filesystem by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'rpc-virtqemud' --raw | audit2allow -M my-rpcvirtqemud
# semodule -X 300 -i my-rpcvirtqemud.pp


Additional Information:
Source Context                system_u:system_r:virtqemud_t:s0
Target Context                system_u:object_r:fs_t:s0
Target Objects                / [ filesystem ]
Source                        rpc-virtqemud
Source Path                   rpc-virtqemud
Port                          <Unknown>
Host                          bartlebyvi
Source RPM Packages           
Target RPM Packages           
SELinux Policy RPM            selinux-policy-targeted-40.16-1.fc40.noarch
Local Policy RPM              selinux-policy-targeted-40.16-1.fc40.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     bartlebyvi
Platform                      Linux bartlebyvi 6.8.7-300.fc40.x86_64 #1 SMP
                              PREEMPT_DYNAMIC Wed Apr 17 19:21:08 UTC 2024
                              x86_64
Alert Count                   1
First Seen                    2024-04-25 19:25:29 PDT
Last Seen                     2024-04-25 19:25:29 PDT
Local ID                      4b0a82d7-77c9-4578-9478-92c03f9b5ef7

Raw Audit Messages
type=AVC msg=audit(1714098329.852:389): avc:  denied  { getattr } for  pid=3334 comm="rpc-virtqemud" name="/" dev="dm-0" ino=256 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:fs_t:s0 tclass=filesystem permissive=1


Hash: rpc-virtqemud,virtqemud_t,fs_t,filesystem,getattr

SELinux is preventing rpc-virtqemud from write access on the file fedora39-TPM-swtpm.log.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that rpc-virtqemud should be allowed write access on the fedora39-TPM-swtpm.log file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'rpc-virtqemud' --raw | audit2allow -M my-rpcvirtqemud
# semodule -X 300 -i my-rpcvirtqemud.pp


Additional Information:
Source Context                system_u:system_r:virtqemud_t:s0
Target Context                system_u:object_r:var_log_t:s0
Target Objects                fedora39-TPM-swtpm.log [ file ]
Source                        rpc-virtqemud
Source Path                   rpc-virtqemud
Port                          <Unknown>
Host                          bartlebyvi
Source RPM Packages           
Target RPM Packages           
SELinux Policy RPM            selinux-policy-targeted-40.16-1.fc40.noarch
Local Policy RPM              selinux-policy-targeted-40.16-1.fc40.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     bartlebyvi
Platform                      Linux bartlebyvi 6.8.7-300.fc40.x86_64 #1 SMP
                              PREEMPT_DYNAMIC Wed Apr 17 19:21:08 UTC 2024
                              x86_64
Alert Count                   1
First Seen                    2024-04-25 19:25:29 PDT
Last Seen                     2024-04-25 19:25:29 PDT
Local ID                      58f8d3f2-0ace-4400-b7c7-9f42d4dcccb2

Raw Audit Messages
type=AVC msg=audit(1714098329.853:390): avc:  denied  { write } for  pid=7651 comm="rpc-virtqemud" name="fedora39-TPM-swtpm.log" dev="dm-0" ino=537436 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=file permissive=1


Hash: rpc-virtqemud,virtqemud_t,var_log_t,file,write

SELinux is preventing rpc-virtqemud from relabelfrom access on the directory tpm2.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that rpc-virtqemud should be allowed relabelfrom access on the tpm2 directory by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'rpc-virtqemud' --raw | audit2allow -M my-rpcvirtqemud
# semodule -X 300 -i my-rpcvirtqemud.pp


Additional Information:
Source Context                system_u:system_r:virtqemud_t:s0
Target Context                system_u:object_r:virt_var_lib_t:s0
Target Objects                tpm2 [ dir ]
Source                        rpc-virtqemud
Source Path                   rpc-virtqemud
Port                          <Unknown>
Host                          bartlebyvi
Source RPM Packages           
Target RPM Packages           
SELinux Policy RPM            selinux-policy-targeted-40.16-1.fc40.noarch
Local Policy RPM              selinux-policy-targeted-40.16-1.fc40.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     bartlebyvi
Platform                      Linux bartlebyvi 6.8.7-300.fc40.x86_64 #1 SMP
                              PREEMPT_DYNAMIC Wed Apr 17 19:21:08 UTC 2024
                              x86_64
Alert Count                   1
First Seen                    2024-04-25 19:25:29 PDT
Last Seen                     2024-04-25 19:25:29 PDT
Local ID                      be797438-9c1b-474d-afc0-680ad6cceeeb

Raw Audit Messages
type=AVC msg=audit(1714098329.853:391): avc:  denied  { relabelfrom } for  pid=7651 comm="rpc-virtqemud" name="tpm2" dev="dm-0" ino=538166 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:virt_var_lib_t:s0 tclass=dir permissive=1


Hash: rpc-virtqemud,virtqemud_t,virt_var_lib_t,dir,relabelfrom

If I create a local policy using the suggested commands I’m able to overcome the issue and I can confirm that the process is indeed trying to relabel the SE-Linux tags.

I suspect this is a bug in Fedora 40, it doesn’t make sense to me that a process would need to relabel the SELinux context of an object it’s working with. Does this sound correct? Should this be filed in the Bugzilla?

2

Hi Albert,

I assume you already read this topic: Unable to create new virt-manager vm with software TPM on Fedora 40 (corrected link)

I am not 100% sure if it is the same because the other user seems to have been able to still use swtpm once a machine was setup, and the one avc denial they have shown differs from other reports. However, the data of them is too limited to know for sure.

However, the denials of the ausearch you have presented seem to equal that of the bug report: 2272971 – Error starting domain: can't connect to virtlogd: Unable to open system token /run/libvirt/common/system.token: Permiso denegado

Except that you have additionally the swtpm denial.

I suggest to add your data to the bug report: the ausearch output (with the exact command), a short elaboration of your issue, and maybe comparison of with and without swtpm (I expect the difference will be only the one swtpm denial). Also, add a link to here in the bug report post, and vice versa.

This might help the policy team to improve their understanding of the overall issue and its relations.

Supplement/clarification: even if you can run VMs without swtpm, which seems to be not in common among reports, you have the related denials, so I expect your issue to be related (selinux polices have complex outreaches in these areas, and slight changes in the system might make them behave different). Make the points clear in the report, and also add that autorelabeling (which I would have expected anyway) does not help you, but given the avc denials you have logged, I don’t see the need for an additional report.

Also, even if it works without swtpm, check out if the denials are logged anyway or not.

Feel free to give us information here first before filing a post in the report if you want.

2 Likes
3

I confirm the issue in system mode, but it works fine for me in session mode:

virt-manager -c qemu:///session

qemu:///system vs qemu:///session | Cole Robinson

Update:
Unable to create new virt-manager vm with software TPM on Fedora 40 - #48 by vgaetera

2 Likes
4

That might be worth a short post in the bug report. In either case, active VMs create an outreach beyond the user account resources. If SELinux does not intervene in session mode, that tells us something about the policies.

If we get some confirmations that this helps in multiple cases, we might even add it to the Common Issue as workaround. It might help to avoid some users to disable their SELinux :wink:

5

Any progress?

6

You can subscribe on the RHBZ ticket linked above.
Or just use session mode and forget about this issue.

7

An update that solves the issue has been pushed to stable: If you experience the problem, please do sudo dnf update --refresh , install all updates and then reboot after the updates have been installed

If you still experience the issue after that, let us know here.

8

I also have a similar issue, I have a couple of VMS that use TPM and neither will start with selinux active. If I disable it they start fine.
I get this message in the log:

May 01 08:33:11 Precision7760 setroubleshoot[11164]: SELinux is preventing swtpm from write access on the file /run/libvirt/qemu/swtpm/1-MyVM-swtpm.pid. For complete SELinux messages run: sealert -l 70415a9c-e043-41a0-a61a-58775c389c3b
May 01 08:33:11 Precision7760 setroubleshoot[11164]: SELinux is preventing swtpm from write access on the file /run/libvirt/qemu/swtpm/1-MyVM-swtpm.pid.
                                                     
                                                     *****  Plugin catchall (100. confidence) suggests   **************************
                                                     
                                                     If you believe that swtpm should be allowed write access on the 1-MyVM-swtpm.pid file by default.
                                                     Then you should report this as a bug.
                                                     You can generate a local policy module to allow this access.
                                                     Do
                                                     allow this access for now by executing:
                                                     # ausearch -c 'swtpm' --raw | audit2allow -M my-swtpm
                                                     # semodule -X 300 -i my-swtpm.pp
                                                     
May 01 08:33:11 Precision7760 setroubleshoot[11164]: SELinux is preventing swtpm from write access on the directory swtpm. For complete SELinux messages run: sealert -l 252722f5-c02c-4684-ad9b-c670f752766c
May 01 08:33:11 Precision7760 setroubleshoot[11164]: SELinux is preventing swtpm from write access on the directory swtpm.
                                                     
                                                     *****  Plugin catchall (100. confidence) suggests   **************************
                                                     
                                                     If you believe that swtpm should be allowed write access on the swtpm directory by default.
                                                     Then you should report this as a bug.
                                                     You can generate a local policy module to allow this access.
                                                     Do
                                                     allow this access for now by executing:
                                                     # ausearch -c 'swtpm' --raw | audit2allow -M my-swtpm
                                                     # semodule -X 300 -i my-swtpm.pp

I did try running the suggested commands in the log and they did not change the error.
I have installed all updates and done a ‘relabel’ as suggested in other threads and the error is still present.

9

@bug2k24 We already found out that the solution does not work if swtpm is used. So far, the denials I see in swtpm cases overlap but are not 100% identical, but I still think it is the same origin ( swtpm-selinux) in all cases. Currently, this is primarily tackled here: Creating new VM with TPM using virt-manager results in SELinux-related error - #4 by py0xc3

Yet, it would be nice if you provoke the issue once, let us know the very time you provoked it, and then wait at least 10 seconds and send us the full output of ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today

Extracts of only one second are maybe not covering all related denials.

10

Here’s the output after attempting to start the vm at 9.26

type=AVC msg=audit(01/05/24 09:26:02.155:584) : avc:  denied  { write } for  pid=113794 comm=swtpm path=/run/libvirt/qemu/swtpm/1-MyVM-swtpm.pid dev="tmpfs" ino=4456 scontext=system_u:system_r:swtpm_t:s0 tcontext=system_u:object_r:qemu_var_run_t:s0 tclass=file permissive=0 
----
type=AVC msg=audit(01/05/24 09:26:02.157:585) : avc:  denied  { write } for  pid=113794 comm=swtpm name=swtpm dev="tmpfs" ino=4242 scontext=system_u:system_r:swtpm_t:s0 tcontext=system_u:object_r:qemu_var_run_t:s0 tclass=dir permissive=0
11

Is this the full output of ausearch? (if so, I will move your posts to another topic, which covers the swtpm issue with only the one swtpm denial)

1 Like
12

General info: there are currently three open topics that cover likely the same problem origin, although the denials are not equal but overlapping (the difference in the denials can be explained by, e.g., differences in the configuration of host or guests):

I do not merge them at this time since we do not know 100% that they are identifcal. SELinux policy issues are complex (but I am confident at this time that a policy fix will solve all three :wink: ).

Everyone who is affected by the issue is encouraged to provide the full output of ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today after provoking the issue so that we can compare their denials, and add a short elaboration of your very issue. Please compare your ausearch output with the denials of the very topics and post them in the relevant one! Unless other information comes up, we will open a bug ticket later today or tomorrow in this one (no worries, we will link the ticket to all topics :wink: ).

I expect the issue is a policy in swtpm-selinux. That can be solved with an update once the maintainers untangled and fixed it.

1 Like
13

Thanks for that, the earlier messages looked to have the same error, here’s the full list since boot time:

type=AVC msg=audit(01/05/24 08:22:08.247:300) : avc:  denied  { connectto } for  pid=3334 comm=abrt-dump-journ path=/run/systemd/userdb/io.systemd.Machine scontext=system_u:system_r:abrt_dump_oops_t:s0 tcontext=system_u:system_r:systemd_machined_t:s0 tclass=unix_stream_socket permissive=0 
----
type=AVC msg=audit(01/05/24 08:22:08.248:301) : avc:  denied  { connectto } for  pid=3334 comm=abrt-dump-journ path=/run/systemd/userdb/io.systemd.Machine scontext=system_u:system_r:abrt_dump_oops_t:s0 tcontext=system_u:system_r:systemd_machined_t:s0 tclass=unix_stream_socket permissive=0 
----
type=AVC msg=audit(01/05/24 08:23:29.644:322) : avc:  denied  { write } for  pid=9345 comm=swtpm path=/run/libvirt/qemu/swtpm/1-MyVM-swtpm.pid dev="tmpfs" ino=4244 scontext=system_u:system_r:swtpm_t:s0 tcontext=system_u:object_r:qemu_var_run_t:s0 tclass=file permissive=0 
----
type=AVC msg=audit(01/05/24 08:23:29.644:323) : avc:  denied  { write } for  pid=9345 comm=swtpm name=swtpm dev="tmpfs" ino=4242 scontext=system_u:system_r:swtpm_t:s0 tcontext=system_u:object_r:qemu_var_run_t:s0 tclass=dir permissive=0 
----
type=AVC msg=audit(01/05/24 08:33:08.674:441) : avc:  denied  { write } for  pid=11156 comm=swtpm path=/run/libvirt/qemu/swtpm/1-MyVM-swtpm.pid dev="tmpfs" ino=4337 scontext=system_u:system_r:swtpm_t:s0 tcontext=system_u:object_r:qemu_var_run_t:s0 tclass=file permissive=0 
----
type=AVC msg=audit(01/05/24 08:33:08.675:442) : avc:  denied  { write } for  pid=11156 comm=swtpm name=swtpm dev="tmpfs" ino=4242 scontext=system_u:system_r:swtpm_t:s0 tcontext=system_u:object_r:qemu_var_run_t:s0 tclass=dir permissive=0 
----
type=AVC msg=audit(01/05/24 09:26:02.155:584) : avc:  denied  { write } for  pid=113794 comm=swtpm path=/run/libvirt/qemu/swtpm/1-MyVM-swtpm.pid dev="tmpfs" ino=4456 scontext=system_u:system_r:swtpm_t:s0 tcontext=system_u:object_r:qemu_var_run_t:s0 tclass=file permissive=0 
----
type=AVC msg=audit(01/05/24 09:26:02.157:585) : avc:  denied  { write } for  pid=113794 comm=swtpm name=swtpm dev="tmpfs" ino=4242 scontext=system_u:system_r:swtpm_t:s0 tcontext=system_u:object_r:qemu_var_run_t:s0 tclass=dir permissive=0

I had previously tried to start the vm earlier which is shown by the time stamp.

14

Thanks bug. I just saw that I mixed the swtpm denial with the qemu-img denial: the topic that contains only one denial contained actually not swpm but qemu-img.

I leave your posts here since this topic’s denials are closest to yours. I am quite sure that the difference in denials comes only from some configuration differences, so I would avoid to open further topics. But I will mention your output in the bug report so that the maintainers can consider it. If the solution for the others won’t work for you, we can still open a new report. Can you also add a uname -r output?

@kparal I changed my general info post, but I assume you received an email that has the wrong information: the topic with only one denial is not swpm but qemu-img . The posts are now corrected.

15

@py0xc3

~> uname -r
6.8.7-300.fc40.x86_64
1 Like
16

<deleted by author> (the user who solved the issue by re-installing Fedora & updating has the issue again since they rebooted the first time after the installation of the virtualization packages; see bug report)

Additionally, we have now an open bug report you should follow daily and add relevant data (especially if people there ask for some data) in case another update as of today does still not solve your issue:

https://bugzilla.redhat.com/show_bug.cgi?id=2278123

1 Like
17

@py0xc3 Thanks Chris. I have not tested trying to create new VMs, my error is only when trying to start a vm that uses tpm, other VMs start fine.

1 Like
18

The maintainer is off the cuff not able to reproduce the issue: they ask for the exact steps and tools the affected users use from the default Fedora to installing tools/packages (including tools like virt-manager , cockpit and whatever could be linked to virtualization, and how you do install/configure them) up to the point when the issue occurs. Please provide them with the related information: See the comment of 2024-05-01 12:04:56 UTC in the bugzilla ticket BZ #2278123. You can use your normal Fedora accounts in the bugzilla when you click login and then Fedora Account System.

I cannot follow the remaining week, so its up to you to read & provide, and maybe test, what is necessary in collaboration with the maintainer. All the best!

1 Like
19

The maintainer has provided an update that shall solve the issue: it is now in testing. The F40 update has already passed all automated tests.

If you want, it would be appreciated if you test if the package solves your issue and let us know. This way we can respond early.

You can install the update swtpm-0.8.1-7.fc40 with sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-f53eab6892

If you still experience the issue after the update, please provide an elaboration if and how the problem has changed, and let us know the time of a provocation of the issue along with a new sudo ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today output.

1 Like
20

So far it seems the recent update solves all cases that contained a rpc-virtqemud denial.

Since the creater of the topic has no longer appeared since creating the topic, and since we have some indication that this is solved, I mark the update as solution to keep it comprehensible which of the swtpm topics are solved and which not.

The author is free to remove the “solution” mark and let us know here if the issue remains in their case.