Windows gpu passthough (Guest has not initialized the display yet) qubes 4.2

I am trying to make a Windows GPU passthrough vm based off of post 1
after configuring everything from that post I tried to boot the windows iso.
It booted for about a second with a screen that said “Guest has not initialized the display yet” then shut down.
I saw post 2 and tried to turn uefi off but no change.
making a new vm and not passing any gpu to it does boot windows only when I add the gpu it breaks. Is there a workaround or fix for this, any help would be appreciated.

post 1

post 2

I’m experiencing the exact same problem (i’m trying GPU passthrough with linux .iso HVM) and at the moment there doesn’t seem to be a solution.

Lessen dedicated RAM to around 2GB (1.8GB should be safe) just to be sure it works now. If so, you’ll need something like this, for example:

Which release candidate are you using?
I’m able to passthrough a gpu with as much ram as I want on rc3 but not on rc4 for some reason.
On rc4 with more than 3.5G of ram the VM just crashes. If I lower the ram below 3.5, it gives me the “display has not initialized” error.

im using 4.2-rc4
trying to recreate the setup I had on 4.2-rc2 it worked quite well besides audio.
Setting the ram to 2GB i was able to start the system but ill need more ram then 2GB setting the ram higher then 2GB causes the issue with the “Guest has not initialized the display (yet)” error.

I also did patch stubdom with 2G and it does boot with 2GB of ram but no more then that.
Also trying to set things up while using 2GB of ram, my gpu started doing the error 43 thing and i could not find a way to fix that. I have a RTX 4090 like the other 2G patch post

So it worked on 4.2 rc2? Mind trying rc3 and see if it also works with that version?
I have a similar issue where in 4.2 rc4 i cannot do gpu passthrough for some reason, but I don’t have any issues with rc3.

Could you also clarify if the 2GB you refer to is the parameter in the patch, or are you only assigning 2GB of ram to the VM? Or is it both?

And could you also try changing the ram assigned to 3.5GB and see if that changes anything? For me, that is usually the treshold.

I am very new to qubes os and dont entirely know how to switch versions like that I am sorry.
I started using it when rc2 was the latest then left for awhile then completely reset my install a few days ago and installed 2.4-rc4, 4.1 does not work for me.
sorry for the poor wording as well I set my ram for the vm to 2GB and for me it does work but I also used the 2G patch change from the lots of ram post due to me having the same version of card.

Testing with 3.5GB of ram does work for me but anymore then that has the guest display issue.

I see. Thanks for clarifying.
To test rc3 I meant you would need to re-install qubes with a 4.2 rc3 ISO, but given that gpu passthrough worked for you in rc2, I think it would be similar in rc3. You would have to install it to know for sure.

If in rc3 you are successful in passing through the gpu, that would track with my experience, and that would tell me that there is some change between versions causing the issue in our hardware.

Do you mind sharing the specs of the computer you are using?

You could try to patch xen.xml from that guide instead stub. That’s how I got a lots of RAM.

I updated to rc5 from rc3 and the gpu passthrough would not work despite it working before the update. I then tried changing the ram parameter under for the stubroot method to 1.5GB, 1.75GB, 1.95GB, and then to 2GB (the original value that worked on rc3) and it worked again. I don’t have a clue as to why this would work, but it did for anyone who might run to a similar issue.

Sorry, but it’s not clear from what you wrote. After each update you should check if patch survived it. We wrote about that. after this, I apologize, but I can’t be of a bigger help to you. I am sure someone else will jump in. Just be persistent. It’s in everyone’s interest.

Sorry for not being clear. What I did was upgrade my Qubes OS 4.2 rc3 using the Qubes updater.
I assumed that would have upgraded my 4.2 rc3 installation to 4.2 rc5, but I believe there is a bug that Qubes 4.2 rc5 presents itself as 4.2 rc4 in the “About” tab in Qubes Manager, so I’m not sure if I upgraded to 4.2 rc4 or rc5. In either case, after upgrading dom0, the gpu qube would not start, so I followed the steps in the gpu passthrough guide again, which worked. I am currently able to use the dGPU again.

I’m going to try installing 4.2 rc5 from an ISO and see if that installation behaves differently and report back.

Thanks for keeping an eye out for this thread.

1 Like

I was using the stubdom patch successfully to use my nvidia secondary card as a headless cuda compute device flawlessly in Qubes 4.1 for LLMs. I am now on the final version release of Qubes 4.2. I have my HVM qube named gpu_3n5G_LLM and I am encountering the error failed to mount /dev/mapper/dmroot as root file system. In Qubes 4.1 where it was working I had my qube called gpu_llm. I tried re-doing the stubdom step. I see people saying try changing the max ram 4g “parameter” from 3.5 to 2G, is that this line in the nano init step? "max_ram_below_4g=“3.5G” and I change “3.5G” to “2G”? I have tried that with the same result. I would appreciate any advice. I am great at following instructions, but my understanding isn’t great enough to innovate from here. Thank you.

I don’t think this has to do anything with RAM patch or GPU… Did you try to create completely new gpu_ qube?

Perhaps it is a debian-12 issue. I tried with debian-11 and it was a success. Thank you all.

1 Like

yes, change the value in the init file from 3.5 to 2 and see if that works.
Basically, from what I understand, its based on whether or not you can turn off re-sizeable bar in the bios. If you are not able to turn it off, you’ll most likely need to change that value.