Asus GL552VW #22
Comments
|
Just to add to this, the first error here (kvmgt) was down to the kernel parameters not being persisted. My gut feeling without digging into it is that update-grub has been used in the script which doesn't work on fedora, you need This still leaves the fatal vfio-mdev which I'll keep looking into. |
|
After doing the above grub update with a reboot I then get a different set of compatibility information, see below: I'm reading this as "only the dGPU can be passed to a VM, not the integrated". So I changed to config to put false for passing through the iGPU but unfortunately this doesn't improve the situation. |
|
After some further digging, I think it's because the helper iso hasn't been generated. Looking at the documentation this should be with the iso argument but then looking at the actual mbpt.sh file I think you need to write helper-iso. Running with helper-iso generates the required file and clears this specific error. |
|
A further test I've perfomed is removing the vfio relevant commands from qemu and checking windows would boot if given the chance, which it does (I can see it with spice). This indicates that the issue is more than disabling the dGPU in the host bricks fedora rather than it not actually being able to passthrough. Will investigate later. |
|
After narrowing down the hang it's on driverctl set-override. Running driverctl list-overrides returns Unsure if this is just a fedora 35 issue, but will keep investigating when I can. |
|
Got a little further by installing the proprietary Nvidia drivers but that just opens an extra can of worms with the system not booting, and bumblebee setup being dodgy (as you well mention in the guide!) I think I'm done trying to get this to work on Fedora and chalk this up as a loss unless anyone has a good idea for a next troubleshooting step. |
|
Hey, thanks for the feedback. I agree that I really need to merge the windows-unattended-install into the master. Considering that the master branch has so many issues for Ubuntu users there isn't really a good reason not to do it anymore. It's possible that some adjustments have to be made in order to support Fedora 35. I have only tested that branch on Fedora 34 so far. If that still doesn't work for you and you have a 64GB USB stick, it might be worth it to try the Live CD image which you can build by running The helper ISO should be generated automatically whenever necessary. This happens during in the setup ( MobilePassThrough/scripts/main/setup.sh Line 164 in 4a1627a It shouldn't be necessary to install a specific Nvidia driver. If you have either Nouveau or the proprietary one installed you should be fine. Bumblebee is completely untested in regards to the new branch, I advise against setting it up before getting it to work without it. In regards to driverctl I'm not sure. Often times the only way to get a GPU (driver) to behave normally again is a reboot. |
|
Thanks for the response! I have a feeling unbinding the driver just isn't happy on Fedora 35 yet. Under the nouveau driver I got a full hang, and under the proprietary driver I got a shell hang. Other people have experienced something similar (although not Fedora 35 specifically) https://forum.level1techs.com/t/problem-cant-use-driverctl-overrides-on-nvidia-driver/176777 I think what I will do is use the live environment and see if I can get that working. If so I think it would probably be a good idea for those to be the main focus of what's provided? That way it's always a clean install and all variables are controlled. |
|
The live version isn't really meant to be installed though. Its main purpose is to provide a fully automated fool-proof way of testing if GPU passthrough works on a given device or not. |
|
That makes sense. Assuming I get it working on Fedora 34 (both live and fresh), do you have a priority list in mind for which distros you'd like to support? I'm happy to just throw stuff at this laptop for testing. |
|
I think it would be Fedora 34, Fedora 35 and then Ubuntu 21. I can't give you a date on when all this will happen though. |
|
Sounds good. Currently running into issues just building the live iso as there are python modules not installed that are required. Namely it seems to assume you have pip and then also the errors package. Potentially need to look into probing for this ahead of time/ensuring there's a venv setup for python, but in the first instance I'm just seeing if I can install the missing packages. Full trace if you like (btw I'm doing this on a fresh install of 35 as I had the live usb ready to go, so my previous work isn't causing these errors) |
|
If I install python-imgcreate https://yum-info.contradodigital.com/view-package/epel/python-imgcreate/ then the error simplifies a bit, but still unclear what to do. As a next troubleshooting step I'm going to fresh install Fedora 34 to isolate 35 as a source of error. Final trace below: |
|
Seems like MobilePassThrough/requirements.sh Line 64 in 1527df2 I'm not exactly sure about that AttributeError. Seems like an issue with |
|
So I'm now on a fresh Fedora 34 install, which runs into the same issue. I then added pip3 as you instructed and deleted the livecd-tools directory. After re-running this does clear up the pip3 bug, but the module not found still remains. I haven't explicitly installed python-imgcreate this time but I imagine it would just do the same thing. Is that the correct dependency to use? If so I'll try it/dig again later on. |
|
pip3 should do the trick. I don't know what python-imgcreate is. |
|
python-imgcreate is just something I found when trying random things that had the same command, we can ignore it. I think you are right that the issue is with livecd-tools as if I simply run editliveos I get the same module error. I'll try with an older version as you say. |
|
Was that indeed, the latest tagged branch livecd-tools-28.1 is now building the image without problem so far. I think we'd want to update the script to have I'll let you know how the live os does! |
|
I'd say it would probably be best to just hardcode the current release into the -b flag on the clone because who knows if their next release will actually be bug-free. I had many issues with older releases before. |
|
Yeah that makes sense, doesn't really need to be updated. Unfortunately, the live environment in f34 runs into similar problems as f35 did. When I next get time I'll look at doing the same fixes I did to get the f35 version almost working but in a full f34 install. Hopefully I can actually unbind the dGPU in f34. |
|
I got it working on f34! Well, not really. I got the windows install to actually fire with the gpu being passed through, however it did run into error 43. My understanding from recent news was that nVidia was going to lift this specific restriction though, so assuming that gets removed it should be good to go. Seamless via RDP and Looking Glass are things I'd like to look into but will skip it for now due to the 43. To recap, the issues with the script (ignoring live os) are: All of the above sound super fixable and could be included in the script. |
|
Thanks for summarizing. I'll try add those changes when I have some time. Regarding error 43, the following options may help: And if you can get your hands on the DGPU ROM, the following may help as well: Also, the Nvidia driver within the VM needs to be somewhat up to date. And if it's still not working maybe it would be worth a try to install the driver provided by Windows Update in case it does provide one. |
|
Thanks! I was using the default options which include those two so unfortunately they have already been tried. I didn't manage to get absolutely everything updated though before running out of space on the default 40G vdrive. Maybe if absolutely everything was up to date it would work so I'm trying again with 100G. If not I will investigate trying to find the ROM as you suggest. |
|
A further update. I actually think the hang I got when I unbinded the dGPU on f35 was caused by X11, as I can recreate this now on f35. On wayland there is no such issue - odd as usually wayland is the difficult one! Being fully updated ensures that the intel iGPU gets passed through fully but I still get a 43 on the dGPU. I will take a look into getting the ROM/ any other 43 workarounds. |
|
Had a go with a rom I found here tavk/ovmf-vbios-patch:edk2-stable201905 Couple things, for this section of the script to work the user must have done the initial docker setup, and pulled and built your patch repo as documented on docker hub. Secondly the path to the rom cannot be in the root of the project directory or docker create will through a bug. Not that much of a problem just should be documented the roms need to go in another folder. However upon running this the patcher fails to compile. I've attached the dump if it helps at all. I might keep investigating the news around 43 as I'm surprised to still see it to be honest. |
|
Is there a rom hardcoded into the Docker image or what do you mean? In order to patch the OVMF with the rom, you just need to set It is then being used in the vm.sh script: MobilePassThrough/scripts/main/vm.sh Line 655 in 1527df2 The easiest way to get your hands on the vbios rom is to search for it here: https://www.techpowerup.com/vgabios/ Since I haven't been able to build the Docker image from source using the Live version (which I usually use to verify that the project in its current state works) due to complicated disk space issues, I haven't actually tested that in a while. In your dump it says Maybe this could be caused by a faulty vbios rom. I'm not sure to be honest. |
|
So I think the reason the vbios setup docker pull didn't work is that the script assumes a) docker is installed, b) docker can be ran without sudo and c) the user has logged into docker in advance so they can pull it from your hub. As I was on a fresh install this wasn't the case. Not really an issue, but perhaps something that should flag a bit louder as I hadn't noticed it had even tried. I got the rom from the same source (techpowerup) but it's untested because they don't have an official one for the 960M. The author of the unofficial one does reference another notebook though so I think the next move is for me to install windows and then use gpu-z, hoping that as you say it's just a faulty rom rather than something wrong in the code. |
|
So unfortunately neither gpu-z nor nvflash work for this laptop, the GPU bios is too integrated into the system bios. There may be some way to do it with DOS apparently but it doesn't seem like a great use of time. I'll keep looking around on forums and such but otherwise I think he's dead Jim. |
|
Okay one more thing you can try is downloading a bios update for your laptop and then use the vbiosfinder (which should be installed into the thirdparty directory) to extract the roms from it. Docker should have been installed during the setup MobilePassThrough/requirements.sh Line 34 in 1527df2 Also, the scripts ru docker with sudo, so that shouldn't be the issue. And last time I checked, you only had to log into docker hub if you wanted to push an image or if you reached their rate limit. I do however remember having a weird issue where a faulty docker installation forced me to log in in order to pull some images. |
|
Yeah odd with docker then, not sure what caused the login to be required. So I've had an initial look into for this laptop and Asus also use a proprietary method for updating bios. (See here) They don't provide an exe to update on their website, but a binary file which isn't the full bios. You then use their tool to complete the file when you want to flash. For a slightly different asus situation I saw a post about trying to use a hexeditor to hack it together, however I think I'd need to by a physical tool to rip the current bios. There is however a promising guide here which reads to me like the exact thing I want, I'll report back if it actually works. |
|
With some skulduggery I now have a folder of about 1000 ROM files which have been extracted from my bios, one of which should hopefully be the file I need. |
|
There are two more ways I can think of to get your hands on the actual bios file that gets written to the SPI flash chip. Extracting the vbios roms from that file should work fine with vbiosfinder then. The first and simple method is to find one of the many ebay sellers that sell bios chips and kindly ask if they can sell you the raw bios file instead of flashing it on a chip and sending you that chip. The second option is buying an SPI programmer with a clamp adapter. You can then open your notebook and attach the clamp to the SPI flash and then use the programmer connected to a second computer to dump the bios from the chip directly. I've also used it in the past to flash a modified (and thus unsigned) bios image. You can of course also combine the two methods. (Buy the chip from ebay and then dump the file using the programmer.) Disclaimer: I can't guarantee that the programmer/clamp would actually fit the chip. And it might be possible for those chips to have a fuse that the manufacturer can blow to make them write-only. One more thing: Are you booting in UEFI mode or legacy mode? I'm just asking because I've had many problems with GPU passthorugh VMs when the host was booted in legacy mode. |
|
Thanks for such an indepth response! I've got the patcher churning through the roms produced by PhoenixTool for now so fingers crossed one of those will actually work. I think I'd happily try the first two of those approaches but the third is outside of my expertise unfortunately. Time will tell how extreme I need to go! If my last ditch software solution doesn't work I'll give that ebay seller a message. Out of curiosity, I think you said in another thread that you'd got this working with an xps-15. If so, would you mind linking me to the exact model? I've also got one which is what I'd ideally use longer term, the Asus was more of a test device for this methodology. Oh and I'm in UEFI mode unfortunately! |
|
That XPS 15 was a Dell XPS 15 9575 2-in-1 notebook/tablet with one of these very rare Intel CPUs that have a built in AMD GPU. At the time of writing I can not recommend that model because even though GPU passthrough works, you will find no information on how to work around error 43 with those weird Intel CPUs online. I think it wasn't even known that non-Nvidia GPUs could run into that error as well until I tried it with that device. |
|
Interesting! The one I have has an Nvidia GPU so might be smoother, who knows. I have both good and bad news. The good news is I actually managed to get vbiosfinder to spit out two roms (presumably one for iGPU, one for dGPU). The bad news is that neither of them actually worked, still resulting in error 43. I'm not sure what's going on in this case because they look like valid files as the patcher actually runs successfully. I have one further avenue before giving up though. I generated that vbios from The bios from asus' website and it's actually a newer version than what's currently running on the host. Potentially upgrading the bios on the host could help? It does seem unlikely though. |
|
You are correct in that the two files are for the iGPU and for the dGPU. Vbiosfinder names them vendorid:modelid (if I recall correctly). Googleing the vendor ids will tell you which one is Nvidia and which one is Intel. You should try to use both of them at the same time. Updating the UEFI often fixes a lot of low level hardware issues as well. So it would generally seem like a good idea to update it. If you're still getting error 43 then, I would try some older versions of the Nvidia driver and also google if anyone else had success with that GPU model. |
|
Some updates of what I've tried. Using both ROMs at the same time unfortunately didn't see any improvement. Flashing to the updated bios so the host and guest are in line made a change, but didn't resolve the 43. To unpack that a bit, with the new bios I get a KVM crash if I patch the vbios on a fresh install. However this crash goes away if I install windows without patching and then on a subsequent start include the patch. Still doesn't fix the 43 though. The error is similar to this forum post, but I've not seen a solution as yet. |
Hi there
First - thanks so much for this repo, it's super useful to have all this information in one place! Below is a description of what happened as I tried to get this running, hopefully it will help! Secondly, apologies in advance for the long post, I’ve tried to include everything I ran into in order to find areas where the documentation could be improved.
I've had a go at using it on a clean install of Fedora 35 with an Asus GL552VW. That is an intel i7-6700HQ and an Nvidia 960M.
I'd recommend either pulling the windows-unattended-install branch into main OR adding a big flag on the master readme that this is the branch to currently use, as the master branch currently doesn't work (as referenced in other issues).
In order to get my dGPU to appear in the check script I had to set kernel parameter intel_iommu=on. It would be handy to add this to the readme (both that it needs to be done, and how to set a kernel parameter for newcomers).
I then ran into an issue where spice would give a connection refused, leading to a system hang as you don't start the vm quick enough because the default port in the config script had changed to 5904, but the docs in master still say 5900. I then realised that this is again just due to docs, as I had the git page on master still (my fault).
I then ran "auto" as is referenced in the unattended-win-install branch readme. This failed because SERVICE_NAME was ambiguous and so the service to run on next boot wasn't set - this error occured in /scripts/utils/manager-specific/service/systemd. I tracked this down to line 187 of setup.sh where the command line arguments were in the wrong order at least for my setup. I switched them around and reran but the service is just set to run auto again so nothing happened.
From here I then attempted to run the stages individually to try and work out what was happening. In this case the main issue was that the install was failing because the default vm-file names (such as the windows 10 iso), don't match the file names as downloaded by default in the setup script. This means that the install script doesn't work, but still unloads your dGPU leading to a crash. It was very helpful to have the dry-run parameter to work this out so thanks for that! It would be helpful if the script detected a failed install and didn't unload the gpu however.
The first reason I could see for a failure of the install script was qemu-img not found. I then installed that package separately, perhaps an early step failed to grab it.
The next error became “failed to connect to the hypervisor” from qemu. What seemed to work is installing libvirt from Discover and then importantly rebooting.
This is where I’ve stopped for now as I’m on the edges of what I know without significant further reading. The bottom line is I can’t create a vGPU due to a linux error. The remaining errors that cause the install to fail can be found in the output of my install dry run below. Any pointers of next steps to troubleshoot would be appreciated! I will try and investigate this further when I get more time.
The text was updated successfully, but these errors were encountered: