On 24/09/2021 06:52, Sam Varshavchik wrote:
Sam Varshavchik writes:
Ed Greshko writes:
On 20/09/2021 00:08, Sam Varshavchik wrote:
Is anyone else getting this error in the "Security processor troubleshooting" (21H1, with all updates installed)?
It has been nearly 2 months since I worked on this. But, yes, that is what I was seeing. No matter what I did
I could not get passed that issue. I gave up and moved on to installing Win11.
I think I figured it out. That message has nothing to do with the TPM chip per se, real or emulated. In "Security Processor" there was a similar, vague message, but with a "more information" link. That goes to a web page, which is full of Microsoftese. Rather than describing what it wants in clear technical terms, it meanders on topics like "basic security requirements", "enhanced security requirements", and similar handwaving. I reread that five times, then I figured out that it wants UEFI+Secure Boot, to make this warning message go away.
All the Win11 press was about the TPM 2.0 requirement, there was no mention of a UEFI+Secure Boot requirement for upgrading, but I wouldn't want to draw any conclusions.
I tried to give one more college try with another, licensed, VM. I found very useful reading material here: https://ogris.de/howtos/windows-uefi-virtio.html
So, I took my other, licensed, Windows 10 VM and tried the same thing I did with the other one, except that this time I also converted the raw disk image to qcow2. Afterwards, like before, I created a new VM from scratch, pointed it to the new disk image and manually added TPM 2.0 hardware. The new VM booted fine.
This looked promising. I shut it down, created a qcow2 snapshot, booted the VM, ran mbr2gpt, as described there, to convert the MBR to GPT. mbr2gpt first claimed that it succeeded, but also complained something about ReAgent.xml, and told me that I need to enable EFI in my firmware, when I reboot. So I shut down the VM, creating another VM, this time selecting the secboot EFI firmware.
Windows did boot, but came up in 640x480 mode with basic drivers, unactivated, and refused to activate, wanting me to pay for a license. The explanation it gave me: new hardware. This was a retail license, though, which should be transferable.
I cut the experiment short, shut down the EFI VM, restored the qcow2 snapshot, and went back to the BIOS VM. It came up fine.
I see two possible reasons: 1) It's been documented how Windows unactivates after what it considers to be too many hardware changes, or maybe 2) it is necessary to update to EFI first, then add a TPM module. The new EFI VM has its own separate TPM module, so Windows doesn't find the same TPM chip it already saw, so it does not activate.
It's unclear if Win11 requires just a TPM chip, or TPM+secure boot. I don't recall anyone mentioning a secure boot requirement, just TPM, which does seem to work, by creating a new VM.
In a couple of months, if neither one of my VMs offer a Win11 upgrade I'll try to switching to an EFI VM, and copy swtpm's data to the new VM's swtpm, before the first boot, and see what happens…
All I can say is you have more patience with Windows than I have. Way more. :-) :-)
--
Nothing to see here
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
