I found it in ps 4 113 1814 758 20 0 13772 5784 - S ? 0:00 \_ /usr/bin/swtpm_setup --tpm2 --tpm-state /var/lib/libvirt/swtpm/202a34a9-2ee2-4826-b206-c249f535be90/tpm2 --vmid testguest:202a34a9-2ee2-4826-b206-c249f535be90 --logfile /var/log/swtpm/libvirt/qemu/testguest-swtpm.log --createek --create-ek-cert --create-platform-cert --lock-nvram --not-overwrite
That 113 is swtpm $ id 113 uid=113(swtpm) gid=121(swtpm) groups=121(swtpm) In swtpm itself the executing user/group was changed (see the already referenced mir bug) to be more secure. The biggest remaining difference here vs the working execution with root is that user/group. We have adopted that behavior as requested by Steve in bug 1948880. In fact without 1948880 due to the respective user/group change in the swtpm package we encountered the very same issue we see now - and it was resolved by that upload. Maybe the updates to libtpms/swtpm since then (or anything else) makes it use different directories now. Changing the user libvirt uses to spawn swtpm indeed changes the behavior. It now ends like: Need read rights on signing key /var/lib/swtpm-localca/signkey.pem for user swtpm. swtpm-localca exit with status 1: An error occurred. Authoring the TPM state failed. That at least confirms that we seem to be on the right track. For further tests we'll likely need to purge swtpm + some directories, reinstall it and retry from there. To ensure nothing is just based on former file ownership. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1968131 Title: Starting VM with UEFI firmware fails with swtpm To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1968131/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
