11:08 a.m.
What finally got my existing Win10 guest VM (originally upgraded from Win7)
to see a TPM2 device was the following process:
1) Make a copy of the raw disk image. This isn't really necessary, but I did
this for backup purposes.
2) In virt-manager I created a new VM, pointing to the existing raw disk
image, and directed it to use the canned "Windows 10" operating system
configuration, and also selecting the manual configuration option, and then
using that to add the TPM2 module. Google searches seemed to suggest that
the "TIS" model is the one to use, so that's what I selected.
3) This creates a new VM with the emulated "Q35" chipset, rather thanthe
existing i440fx chipset, that Win7 was originally configured for. This is
the trick, apparently.
When I booted the new VM, Windows 10 went through some noticable setup and
reconfiguration, but it did survive the transplant. The only result was it
required me sign into my Microsoft account (I recommend that the Win10 seat
be registered to a Microsoft account before doing this, this appears to be
the simplest way to avoid license/activation problems). Over the next couple
of minutes Windows10 also popped up occasional prompts about setting up this
PCI device, or that PCI device. But nothing seemed to indicate a problem
with the new VM.
And it now sees the TPM2 device, however it does show a "Device health
attestion isn't available" because "Your device does not support this
feature". After a few minutes it offered me the option to "Clear TPM" to
fix
this issue (initially the button was disabled, but it became enabled a few
minutes after the boot). However that made no difference, this status
remained after the "Clear TPM" and the reboot.
I have another Win10 license which I'll try, later, with the other "CRB"
emulated TPM model, to see if that works fully. It's also possible that this
is it's way of expressing that it knows it's running in a VM. And it now
sees the TPM2 device, however it does show a "Device health attestion isn't
available" status because "Your device does not support this feature".
Is anyone else getting this error in the "Security processor
troubleshooting" (21H1, with all updates installed)?
1:12 p.m.
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.
--
Nothing to see here.
1:24 p.m.
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.
5:52 p.m.
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…
6:04 p.m.
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
9:18 p.m.
Ed Greshko writes:
>
> 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. :-) :-)
This is mostly intellectual curiousity, something to tinker with, and a
learning experience. I learned about qcow2 snapshots by screwing around with
this thing. They are very useful, without them it would be a mess. And I did
learn that qemu is capable of booting Windows 10 in secure boot mode.
When I pick this up again, in a month or two (unless I get a good lead,
earlier) the first step would be to figure out how to create a new VM in
virt-manager but preserve the data in the emulated TPM chip, to see if that
makes Windows 10 survive the firmware transplant. I see that it's in a
directory whose name is te VM's random UUID. So, what will it be? Copy the
existing VM's TPM directory to the new VM when it gets created? virt-manager
seems to automatically start the new VM after creating it, I don't really
see a reason for this behavior, but I'd have to force-off the VM to get its
UUID. I don't remember if I can edit the XML file in the custom installation
mode, maybe I can cut/paste and create a VM with the same UUID, so that virt-
manager-started swtpm ends up loading the same data?
6:44 p.m.
On Thu, Sep 23, 2021 at 6:52 PM Sam Varshavchik <mrsam(a)courier-mta.com> wrote:
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.
When I upgraded some VMs running Windows 7 on VirtualBox to Windows 10
on KVM I had to re-enter the license key for some of them. When you
say it "refused to activate" did you mean that you re-entered the key
and it rejected it? Or that it just didn't automatically accept the
pre-existing key?
9:08 p.m.
Go Canes writes:
On Thu, Sep 23, 2021 at 6:52 PM Sam Varshavchik
<mrsam(a)courier-mta.com>
wrote:
> 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.
When I upgraded some VMs running Windows 7 on VirtualBox to Windows 10
on KVM I had to re-enter the license key for some of them. When you
say it "refused to activate" did you mean that you re-entered the key
and it rejected it? Or that it just didn't automatically accept the
pre-existing key?
The license key is used only when upgrading to Win10. From that point, Win
10 uses some kind of a digital entitlement license. All Win 7 seats that get
a free upgade to Win 10 show the same license key, post upgrade.
Windows 10 only offered to sell a license, in order to activate itself,
before I reverted the snapshot.
9:17 a.m.
On Thu, Sep 23, 2021 at 10:09 PM Sam Varshavchik <mrsam(a)courier-mta.com> wrote:
Go Canes writes:
> On Thu, Sep 23, 2021 at 6:52 PM Sam Varshavchik <mrsam(a)courier-mta.com>
> wrote:
> > 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.
>
> When I upgraded some VMs running Windows 7 on VirtualBox to Windows 10
> on KVM I had to re-enter the license key for some of them. When you
> say it "refused to activate" did you mean that you re-entered the key
> and it rejected it? Or that it just didn't automatically accept the
> pre-existing key?
The license key is used only when upgrading to Win10. From that point, Win
10 uses some kind of a digital entitlement license. All Win 7 seats that get
a free upgade to Win 10 show the sam
Yes, that is how it is *supposed* to work. But in the cases I
mentioned, I had to re-enter the Windows 7 license key to get to
activate. The "digital license" for Windows 10 (which as you
indicated is the same for all the upgrades) would not work - the
Windows 7 license key worked fine.
938
days inactive
943
days old
8 comments
3 participants
participants (3)
-
Ed Greshko -
Go Canes -
Sam Varshavchik