Windows Qubes do not start after upgrading to R4.1

User Support 4.1
#1

I succesfully used the upgrade tool to upgrade Qubes from R4.0 to R4.1
Now, when I want to start my Windows 7 VM’s, I get the error that libxenlight cannot create the new domain. I’ve found this issue: Migrate backups of Windows VMs created under Qubes R4.0 to R4.1 · Issue #7088 · QubesOS/qubes-issues · GitHub
However, that is about imported backups. Also, in that issue, the Windows 7 VM’s actually start for a short time before crashing, instead of the libxenlight error I have.

My Windows 7 VM’s were actually restored backups from Qubes R3.2 into R4.0, as at that time, there was no QWT for R4.0 yet. Uninstalling QWT in Windows crashed the VM and made it unusable, so I never upgraded to a newer QWT, and the installed QWT version is still the latest from R3.2

#2

Maybe you can try to remove all qvm-features from your HVM to try to boot with QWT disabled this way.
You can leave features check-updates and qubesmanager.maxmem_value and remove everything else.
Though I’m not sure if it will disable the use of QWT but you can try.

#3

Did you try this?

#4

Yes, I already ran with debug mode on by default, because of that issue.

#5

How can I do that?
If I execute qvm-features vmname in dom0 terminal, I get this output:

os                          Windows
rpc-clipboard               1
check-updates               
qrexec                      1
gui                         1
service.qubes-update-check  
linux-stubdom
#6

You can remove them with:

qvm-feature -D os
qvm-feature -D rpc-clipboard
...

But I’ve tried it out on my Windows HVM and after I start my HVM the features are automatically set again and QWT works so I guess it won’t help you.

There is also an option to just remove the QWT files from your system but I don’t know if it will help.
You can mount your HWM drive:

sudo kpartx -a /dev/mapper/qubes_dom0-vm--yourvmname--root
sudo mount /dev/mapper/qubes_dom0-vm--yourvmname--root2 /mnt
sudo rm -rf /mnt/Windows/System32/qubesdb-cmd.exe
sudo rm -rf /mnt/Windows/System32/qubesdb-client.dll
sudo rm -rf "/mnt/Program Files/Invisible Things Lab"
sudo rm -rf "/mnt/Program Files (x86)/Invisible Things Lab" # not sure if you have it in Program Files or Program Files (x86)
sudo kpartx -d /dev/mapper/qubes_dom0-vm--yourvmname--root
sudo umount /mnt
#7

Well, I don’t remember having linux-stubdom feature ever, but stubdom-qrexec.
Did you follow this procedure?

#8

It already gives an error at the first command :joy:
failed to stat() /dev/mapper/qubes_dom0-vm-win7–root
I doublechecked the command, it was typed correctly.

#9

I can’t install it… On R4.0, when I executed qubes-dom0-update, it said “using sys-whonix as UpdateVM…” and update would be displayed in red text in the terminal window. However, now it actually opens a separate sys-whonix window. Is that expected behavior? It disappears as soon as updates are found, but then in dom0 terminal it says no updates found. I suppose I have to open a seperate thread for this.

#10

The path to the device is incorrect. Check the directory to find the exact name of the storage device for your VM:
ls /dev/mapper/qubes_dom0*

#11

It is expected

Maybe you could to try to mount it like this, just use respective names. Be sure to have ntfs-3g installed in the VM to which you will attach win7

#12

Ah yes, even after double checking I missed that there is a double “-” before VMname as well. I was able to remove those files and folders, but I still get the libxenlight error.

#13

I was planning to move to Windows 10 anyway now that the new QWT has arrived, so maybe it is easier to just install Windows 10 and mount the private image of my Windows 7 VM’s to copy any data.
Thank you both for the help anyway!