Windows qubes using QWT restored from a 4.1 backup in 4.2 are not bootable

[GWeck]

Qubes OS release

R4.1.2 --> R4.2.1

Brief summary

Currently, there does not seem to be a working way to run Windows VMs using Qubes Windows Tools under Qubes R4.2.1. So putting Qubes R4.1.2 to EOL forces installations with such qubes to select one of the following two alternatives: either discontinue the use of Qubes as a protective shield for Windows or use a deprecated version of Qubes. Both have to be regarded as a regression.

Steps to reproduce

Install Qubes R4.2.1 and transfer existing Windows qubes using QWT, especially using seamless mode (under Windows 7), from an R4.1.2 installation to the new R4.2.1 installation, possibly by restoring a backup. If QWT (version 4.1.68-1 or earlier) was installed in the VMs, they will not be bootable. Removing QWT before the backup and installing version 4.1.69-1 under Qubes R4.2.1 may be successful only if no Qubes GUI Agent is selected for installation. So there is no way to have seamless mode for Windows under Qubes R4.2.1. The Qubes video driver for Windows is not compatible with R4.2.1.

The situation is still worse if one is not able or not willing to accept the risks described in QSB-091, as then only the non-functional version 4.1.70-1 of QWT can be used.

Expected behavior

Windows qubes imported from R4.1.2 to R4.2.1 should retain their complete functionality or, alternatively, EOL of R4.2.1 should be postponed until such functionality is available under Qubes R4.2.1.

Actual behavior

Full functionality of Qubes Windows tools is not available under Qubes R4.2.1, as described under issue #8328.

Additional information

To solve these problems, the following steps seem to be necessary:

• A trustworthy version of the Xen PV drivers is needed. This may be the new version 9.1.0.1, available from the Xen project, but it has to be determined if this version solves the security problems that caused the retirement of previous versions. It also has to be determined if this driver version is compatible with Windows 7 and 11. Probably this needs some cooperation with the Xen project.

• The new drivers have to be integrated into a new version of Qubes Windows Tools.

• A new version of the Qubes GUI Agent has to be provided in order to support seamless mode under Qubes R4.2.1. Hopefully, this new version will also be available for Windows 10 and 11, as @marmarek has said at the Qubes Summit.

[Minimalist73]

It seems that there is some work being done on QWT over here: https://github.com/omeg?tab=repositories

@marmarek Do you have any information on this and what we can expect from it?

[jamke]

@GWeck thank you bringing this up!

@marmarek , @andrewdavidwong is there a recommended way to update to R4.2 and keep working windows qubes (with working QWT)?
Running Windows using Xen of Qubes OS was one of the main features in R1/R2 and now it seems to be kind of abandoned. Do you guys personally use windows qubes at all for something?

[andrewdavidwong]

In order to ensure that the issue tracker is a useful tool for the developers, one of our rules is that every issue must be about a single, actionable thing. When an issue is about more than one thing, we usually reclassify it so that it is about only one thing. We then request that you open separate issues about each of the other things (unless issues already exist for any of those other things, in which case we ask that you simply comment on the existing issues).

In this case, I've done my best to narrow down this issue to what I understand to be the core problem and updated the title accordingly: "Windows qubes using QWT restored from a 4.1 backup in 4.2 are not bootable."

@GWeck wrote:

Install Qubes R4.2.1 and transfer existing Windows qubes using QWT, especially using seamless mode (under Windows 7), from an R4.1.2 installation to the new R4.2.1 installation, possibly by restoring a backup. If QWT (version 4.1.68-1 or earlier) was installed in the VMs, they will not be bootable.

Is QWT installed in the new 4.2 installation?

@GWeck wrote:

Removing QWT before the backup and installing version 4.1.69-1 under Qubes R4.2.1 may be successful only if no Qubes GUI Agent is selected for installation. So there is no way to have seamless mode for Windows under Qubes R4.2.1. The Qubes video driver for Windows is not compatible with R4.2.1.

These sound like two separate, additional problems that are distinct from the one above.

@GWeck wrote:

The situation is still worse if one is not able or not willing to accept the risks described in QSB-091, as then only the non-functional version 4.1.70-1 of QWT can be used.

What exactly do you mean by "non-functional"?

@GWeck wrote:

Windows qubes imported from R4.1.2 to R4.2.1 should retain their complete functionality or, alternatively, EOL of R4.2.1 should be postponed until such functionality is available under Qubes R4.2.1.

The suggestion to delay the 4.1 EOL should be discussed on qubes-devel instead of the issue tracker.

@GWeck wrote:

Full functionality of Qubes Windows tools is not available under Qubes R4.2.1, as described under issue #8328.

This is confusing, because #8328 is about app menu entries, which is yet another distinct problem from the three mentioned above.

@GWeck wrote:

To solve these problems, the following steps seem to be necessary:

• A trustworthy version of the Xen PV drivers is needed. This may be the new version 9.1.0.1, available from the Xen project, but it has to be determined if this version solves the security problems that caused the retirement of previous versions. It also has to be determined if this driver version is compatible with Windows 7 and 11. Probably this needs some cooperation with the Xen project.
• The new drivers have to be integrated into a new version of Qubes Windows Tools.
• A new version of the Qubes GUI Agent has to be provided in order to support seamless mode under Qubes R4.2.1. Hopefully, this new version will also be available for Windows 10 and 11, as @marmarek has said at the Qubes Summit.

In terms of issue tracking, it looks like these might already be covered by #1861 and/or #9019. @omeg, is this correct?

---

@Minimalist73 wrote:

It seems that there is some work being done on QWT over here: https://github.com/omeg?tab=repositories

@marmarek Do you have any information on this and what we can expect from it?

See #1861 and #9019.

---

@jamke wrote:

@marmarek , @andrewdavidwong is there a recommended way to update to R4.2 and keep working windows qubes (with working QWT)?

As far as I know, there is not and will not be until #9019 (and maybe also #1861) are completed, but I'll defer to @marmarek and @omeg on this.

@jamke wrote:

Do you guys personally use windows qubes at all for something?

I'm personally using a Windows qube without QWT as a temporary workaround, but it really doesn't matter what I use.

[GWeck]

When an issue is about more than one thing ...

The effects mentioned in this issue seem to be different, but they are just different symptoms of the same problem, namely the missing availability of R4.2-compatible drivers for QWT.

Is QWT installed in the new 4.2 installation?

Due to QSB-091, QWT is not directly available for R4.2. I installed it from the rpm of version 4.1.69-1 in the repository.

These sound like two separate, additional problems that are distinct from the one above.

It's the same problem showing in different situations: If a Windows VM containing the video driver is restored from an R4.1 backup, it is already broken. On the other hand, a VM without this driver will work under R4.2, but has, of course, no seamless mode. Installing the driver afterward will break the VM.

What exactly do you mean by "non-functional"?

The currently deployed QWT kit version 4.1.70-1 is not a real installation kit for QWT, but just a text file displaying a message that there is no QWT available, due to QSB-091.

The suggestion to delay the 4.1 EOL should be discussed on #1861 instead of the issue tracker.

Done.

This is confusing, because #8328 is about app menu entries, which is yet another distinct problem from the three mentioned above.

It's still the same problem: According to my tests, some of the QWT drivers - I'm not quite sure which ones - break the mechanism which transfers the menu entries from Windows to the Qubes menus.

In terms of issue tracking, it looks like these might already be covered by #1861 #9019.

I hope so, very much!!! 👍

[andrewdavidwong]

When an issue is about more than one thing ...

The effects mentioned in this issue seem to be different, but they are just different symptoms of the same problem, namely the missing availability of R4.2-compatible drivers for QWT.

Okay. In that case, this issue might end up being a duplicate of #1861 and possibly #9019.

Is QWT installed in the new 4.2 installation?

Due to QSB-091, QWT is not directly available for R4.2. I installed it from the rpm of version 4.1.69-1 in the repository.

These sound like two separate, additional problems that are distinct from the one above.

It's the same problem showing in different situations: If a Windows VM containing the video driver is restored from an R4.1 backup, it is already broken. On the other hand, a VM without this driver will work under R4.2, but has, of course, no seamless mode. Installing the driver afterward will break the VM.

What exactly do you mean by "non-functional"?

The currently deployed QWT kit version 4.1.70-1 is not a real installation kit for QWT, but just a text file displaying a message that there is no QWT available, due to QSB-091.

I see.

The suggestion to delay the 4.1 EOL should be discussed on #1861 instead of the issue tracker.

Done.

Sorry, copy/paste error. The link text I originally wrote ("qubes-devel") was correct, but I accidentally pasted a link to #1861 instead of a link to https://www.qubes-os.org/support/#qubes-devel. Fixed now.

To be clear: Please discuss that on the qubes-devel mailing list, not this issue tracker.

This is confusing, because #8328 is about app menu entries, which is yet another distinct problem from the three mentioned above.

It's still the same problem: According to my tests, some of the QWT drivers - I'm not quite sure which ones - break the mechanism which transfers the menu entries from Windows to the Qubes menus.

I don't see how that's the same problem at all. Anyway, you've already opened a separate issue for it.

In terms of issue tracking, it looks like these might already be covered by #1861 #9019.

I hope so, very much!!! 👍

[unman]

On Wed, Apr 10, 2024 at 08:57:46PM -0700, jamke wrote: Sorry for being outright, but Qubes OS once again throws their users under the bus for no reason. The project should have a clear development and evolution plan. Pragmatic one and satisfactory for users. I think, it should be considered and discussed among the Team. Issues like "backuped VMs are not bootable on the closes (next) OS version" or "layout switch is not working properly" should be considered strict **blockers** and everything with releases should be postponed, and the last working version should be kept supported (not EOL) until the issues are fixed properly.

I think you are wrong about this. There is a specific issue with restoring Windows qubes that contain QWT, in a specific configuration. QWT is not available for 4.2 because it is currently deemed insecure. It's insecure in 4.1. I dont think it unreasonable that Qubes does not support installation of insecure software. If it WERE the case that backuped VMs are not bootable, that WOULD be a blocker. But this isnt the present case. It's some VMs in a specific configuration that rely on insecure packages. I dont know about your second issue. It doesnt sound like a blocker as stated.