Windows 11 in Qubes

General Discussion
1

I tried to install the (German version of) Windows 11 from the ISO provided by Microsoft in Qubes R4.0.4. The Setup started well, but terminataed early, stating "This PC does not fulfil the minimum requirements for Windows 11 - probably because of lack of TPM 2.0 or the emulated processor model.

Has anyone else tried it?

1 Like
2

For Qubes R4.1, it is the same behaviour: The setup starts, and then aborts with the same message.

3

Yes,
I first succeeded to install the “early” Win11 versions, but since two weeks the Windows 11 update function fails with the errors of a missing TPM 2.0 and (probably) a missing “secure boot” on that “model” I’ve just running the Windows11 developer preview.

Assume, we have to wait until someone find out about some further changes (to do in the Win11 registry). The known changings, you’ll find in the net at the time, won’t help right now…

Cheers :slight_smile:

4

TPM emulation by Qemu ought to provide an easy way to do that: https://www.smoothnet.org/qemu-tpm/

5

I’ve remember that i’ve once installed win 11 few months ago, but i don’t remember if it was an modified iso or not. Successfully install it but not with qwt.

You may find a non tpm windows 11 iso here Windows 11 (x64) | Team OS

6

An additional note, i building qwt 4.1-65 using windows pv driver 9

7

I have a TPM and went into UEFI to engage it, however I don’t want to engage secure boot, as I fear this might break Qubes 4.0.4 ; say I were to 1) turn on SB, 2) W11 tells me I can install now, then 3) install 4)unengage SB and attempt to use W11 OR Qubes.
Yes, I can back up Qubes, just in case, however I’m pretty sure my Q4.0.4 is a legacy install,
I have 1 OS on each of 2 HDs /SSDs ; and to dual boot, just change OSs in the UEFI settings ;

Maybe a new version of Qubes is coming soon, that is going to require a Qubes reinstall in any event?

8

There is now a documented way to install Windows 11 without TPM, by disabling the TPM check during setup:

  • When you start setup without having a TPM, you get an error message like “This PC does not fulfil the minimum requirements for Windows 11”.
  • Typing Shift-F10 then opens a console window.
  • Here you type regedit to start the registry editor.
  • There you position to the key HKEY_LOCAL_MACHINE\SYSTEM\Setup.
  • Now create the key LabConfig.
  • Position to this key and create 3 DWORD values called BypassTPMCheck, BypassSecureBootCheck and BypassRAMCheck and set each value to 1.
  • Close the regstry editor and console windows.
  • In the setup window, hit the left arrow in the left upper corner. You will then return into the setup, which will continue normally and install Windows 11 without TPM 2.0.

I did all this and was able to install a Windows 11 template in Qubes R4.0.4 without problems. There I even succeeded in installing QWT 4.0.1.3 and get a stable connection to Qubes, following the instructions in Installing and Using Qubes Windows Tools, including relocation of the user directories. Creating an AppVM based on this template worked, too, and file and clipboard copy/paste to/from other AppVMs showed that communication via qrexec works.

So we can say that Qubes already supports Windows 11!!!

Microsoft states that using Windows 11 without TPM can cause errors, but I didn’t see any, so far. They also say that such systems won’t receive security patches, but - I think - that is by far outweighed by running it in the secure Qubes environment.

In the next days I will try this with Qubes R4.1 and QWT 4.1-65. See what happens …

12 Likes
9

For people, having Win11 DEV build already installed and running into the problems above, should follow the instructions on:

https://www.youtube.com/watch?v=abIH_xlufOY

In result BypassTPMCheck & BypassSecureBootCheck need to be placed under HKEY_LOCAL_MACHINE\SYSTEM\Setup (root) and a additional file from here:

https://drive.google.com/file/d/1j0_WgW0QLzwN3Se3Xbq3EOfEF6y3zC7r/view

need to be copied under C:\$WINDOWS-BT\Sources\ so the system will be upgraded to the next Dev build after 22449.xx

10

Some results regarding Windows 11 under Qubes R4.1:

  • The Windows 11 VM created for Qubes R4.0.4 can also be installed on Qubes R4.1.
  • Qubes Windows Tools 4.1-65 can be installed on this system. This is true for the versions from December last year as well as a newly created version according to @jevank. After installation and the necessary reboot, both versions work and connect to qrexec, which can be tested by copying files from/to another VM.
  • After the next reboot, the two Qubes services Qubes RPC Agent and QubesDB daemon are still running, but seem to be zombies. File copy does no longer work, and after qrexec_timeout, the Windows 11 VM is killed by Qubes.
  • After the next reboot, everything works again.

So it seems, that the interface between Qubes and Windows works each other time. Strange. I will check further.

5 Likes
11

this reboot and reboot is really make me hate it. if you have time can you write step by step ? and are you using pv driver 8 ?

12

I was probably over-optimistic. Currently neither Windows 10 nor 11 have a working qrexec with Qubes R4.1, using QWT 4.1-65 (both the old and the current version). The Qubes RPC agent is most of the time, but not always, running, and if it is not running can be started manually, without effect. There is also no diffrence in using the Xen drivers version 8.2 or installing version 9.0 before installing QWT. The result is always the same: After QWT installation and the first reboot, qrexec works, and files can be copied to other VMs. After the next reboot, and from there on always (or most of the time???), qrexec is dead, and the Windows VM will be killed after qrexec_timeout.

Currently, I am using a fully updated version of Qubes R4.1. As far as I remember, QWT 4.1-65 worked with an earlier Qubes Version (about May / June or so). Unfortunately, I cannot recreate this earlier version to test it again. @marmarek: Has the qrexec interface changed in the meantime?

1 Like
13

This seems to be related to Qrexec Agent Starts Incorrectly and too Early on Windows 10 HVM #5462 . If the Qubes RPC Agent is started manually or, for Windows 10, via the startup type “Automatically (delayed)”, qrexec comminication is established and works.

For Qubes R4.0.x and QWT 4.0.3.1, this error could be solved by installing xenvbd and xenbus version 9.0.0. before QWT. For Qubes R4.1 and QWT 4.1-65, I had no success with this procedure. Perhaps QWT 4.1-65 uses the version 8.2 drivers anyway.

Is there a possibility to build QWT 4.1 with the version 9.0 Xen drivers?

14

I have try but no success, i might wrong but not sure.

15

What Windows 10 iso do you use? I’ve just tried with win10x64-ltsc-eval from qvm-create-windows-qube and cannot reproduce such issue.

16

Windows 9.0.0 pv driver has an issue while uninstall procedure.
https://lists.xenproject.org/archives/html/win-pv-devel/2020-10/msg00019.html

Perhaps this is the core problem you observed? Could you try setup w/o 9.0.0 drivers at all?

17

I am using a Windows 10 VM originally created from Windows_10_1909_x64_de.iso (Windows 10 Professional), upgraded to 20H2 in Qubes without QWT, and then installing QWT. I could try to use a new installation with a 21H1 kit.

18

I also tried with out any 9.0 drivers, just QWT4.1-65. No difference.

19

Using both the German versions of Winodows 10 21H1 Pro and 21H2 Pro (aka Windows 11) in VMs newly created under Qubes R4.1, I got the following results with QWT 4.1-65, using the Xen drivers version 8.2:

  • After installation of QWT and reboot, qrexec works and can be used for files and clipboard copy.
  • After the next reboot, both QWT services are running in Windows, but do not establish qrexec communication with Qubes, and the VM is killed after qrexec_timeout.
  • After the next reboot, the services are working again, and so on - each second time working or not.
  • The services - working or zombie - are started if they were running before the previous shutdown of Windows, irrespective of their startup mode (Automatic as installed, or Manual).
  • You can try to shutdown the services by using the Windows service manager, or the net stop command. Stopping the QrexecAgent will crash the VM if the zombie processes are running and just stop this service if the live processes are running, Stopping the QdbDaemon behaves a bit different: If the zombie processes are running, Windows will crash with the stop error %x0000dead in the xenbus.sys driver, but if the live process is running, both services will shutdown o.k., and can be restarted by using the service manager, or the net start QrexecAgent command, which will start both, and they will establish qrexec communication.

This behaviour can be used to create, as a workaround, a working version of QWT:

  • First, stop the QWT processes using the command net stop "QdbDaemon" /yes, which will stop both services. If the VM crashes, which will happen with a 50 % probability, just reboot and do it again.
  • Then, set the startup type of both processes to Manual by using the Windows service manager or by executing a file Quebes_Manual.reg, containing the following text:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\QdbDaemon]
"Start"=dword:3

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\QrexecAgent]
"Start"=dword:3

  • Shutdown and Reboot Windows. Within the qrexec_timeout time, execute the command net start "QrexecAgent". This will start a working version of QWT running both services. In order to start the services automatically, this command should be put into a file in the AutoStart directory.
  • In order to retain this working version of the QWT services, they have to be stopped before shutting down Windows again. Instead of using the normal shutdown procedure, create a file Qubes_Shutdown.cmd, containing the text

@echo off
net stop "QdbDaemon" /yes
choice /t 5 /d 0 /c 0 > nul
shutdown /s /t 0

  • and execute this file to shutdown the VM, so next time it will start without running the QWT services. (The curious choice command just introduces a 5 second wait before shutdown.)

The whole procedure is not nice, but it is working. Perhaps, with the version 9.0 of the xenbus driver in Qubes Windows Tools, it may be unnecessary, but this driver will have to be included in the QWT creation. Otherwise, it would help if QWT startup followed the startup type of the services and would start them only if this startup type was set to Automatic.

I also tried the version 9.1 drivers, but these cannot be installed at all.

2 Likes
20

Perhaps this is shutdown issue. Did you disable hibernation with powercfg -h off, if not could you try?

1 Like