Net and USB qubes fail to start with Nvidia 2070 inserted

User Support Hardware Issues
1

Hi Everyone,

I was wondering if anyone has run into the problem of the NET and USB qubes failing to start, when having an Nvidia 2070 installed. It boots fine without it. When installed it just waits forever, for those two system qubes and never reaches login…

Thanks for any advice or experience shared!

Klaus

1 Like
2

Hi

It is likely that the identifiers of devices used by sys-usb and sys-net change when you have the NVIDIA card plugged in. Both qubes run as HVM with hardware attached to it, and this requires stable IDs because the passthrough devices list is static.

A solution would be to use the command line parameter that prevent qubes from starting at boot (I don’t remember its name sorry), so you could fiddle in the qube settings to change the IDs (first, check it’s the real issue :sweat_smile: )

2 Likes
3

Do you mean the “qubes.skip_autostart” kernel option?

EDIT: so the course of action would be:

  1. boot up normally, without the Nvidia board; in QubesManager, use the Settings for sys-usb and sys-net to make a note what Devices are connected to them. Make a note (screenshot) of all the devices present.
  2. shutdown and insert the Nvidia card
  3. stop the normal qubes boot and add qubes.skip_autostart
  4. only dom0 starts; start QubesManager and in the sys-usb Settings, look for the differences and idenftify the USB controller; make the change
  5. repeat for sys-net
  6. start sys-usb and sys-net, or reboot
3 Likes
4

Sorry for the lag here. I’ve finally got some time to try this. While it definitely solved the [failed] messages in the output, it still hangs when it gets to starting:

  1. lightdm.service
  2. plymouth-quit-wait

I do have control of the box at this point and ctrl-alt-delete is responsive. However I never make it into a GUI. DOM0 is running at this point. Any advice as to what I should try? I did put on the command line after ‘quiet’ qubes.skip_autostart and since I now have all [ok] for startup messages, assuming it worked.

Thanks and have a good one…

1 Like
5

Did you put

qubes.skip-autostart

or

qubes.skip_autostart

on the line (after quiet)?

:slight_smile:

1 Like
6

I used an underscore, sorry for that typo and the ensuing confusion. I’ll edit it out hehe.

1 Like
7

When you see the plymouth-quit-wait, can you press ctrl-alt-F2 and get to a text login prompt?

If so, can you try to login and run

startx

It will probably fail with some messages - but it should also drop a logfile as

~/.local/share/xorg/Xorg.0.log

Maybe that logfile can give some hints to the problem?

:slight_smile:

1 Like
8

I had tried to get a shell but it kept switching back to the 1st one. Next, I put nomodeset on the kernel line and got it to boot with this card installed. I’m now working to figure out how to boot up without that parameter! It seems to be something with X11 configuration that is the problem. I’ll keep working and keep those suggestions coming, thanks.

1 Like
9

When you read the Xorg.log file, do you see:

xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted)

and/or

(EE) Screen(s) found, but none have a usable configuration.

?

:slight_smile:

1 Like
10

I have the same issue with sys-net not booting with a BE200 card when I use either a nVidia GTX1080 GPU or Hyper M.2 Gen 5 card. Does this mean the initial configuration is set and any new/different device always require the system to be re-configured? This would explain some things, but sounds odd. Am I miss-reading this?

I saw another have a similar issue as mine on another platform using Arch and thought a kernel issue (they are pushing an update for the Arch issue).

1 Like
11

Getting failed to open DRM device in the log. I tried to generate configuration via ‘Xorg -configure’ but that fails with number of devices found doesn’t match what’s configured. Is there a way to blow away old configuration? I feel that after installing the Nvidia card it might have changed location…

1 Like
12

I hit the problem with kernel 6.12.5-2.qubes.fc37.x86_64 - manually selecting one of

  • 6.6.68-1.qubes.fc37.x86_64
  • 6.6.65-1.qubes.fc37.x86_64
  • 6.6.48-1.qubes.fc37.x86_64

kernels, my machine boots fine … :-/

I have an ATI card though, so might be a different problem with the same symptoms …

:slight_smile:

1 Like
13

Yes exactly

1 Like
14

Who would have thought, just getting a stupid nvidia card into my existing configuration would be such a pain. I haven’t even started working with it in the HVM yet! My oh my…

1 Like
15

Ok, the solution to my xorg session starting was in the follow steps:

  • Shutdown and remove Nvidia card
  • Boot up and generate a working xorg.conf: Xorg -configure
  • Shutdown, install Nvidia card and boot up in run level 3. Place configuration in /etc/X11/xorg.conf.d/
  • Modify the kernel params and add:
  • GRUB_CMDLINE_LINUX: rd.qubes.hide_pci
  • GRUB_CMDLINE_XEN_DEFAULT: nomodeset rd.driver.blacklist=nouveau efi=no-rs

After that, it both booted and launched a graphical environment which I further configured via the display applet.

I had no idea I would spend over 7 hours working through this one. I haven’t even got the card working in the HVM, so I can play a simple game like World of Warcraft lol.

I’ll save the next steps for a different post. Thanks everyone for your help, much appreciated. Your pointers about the qubes that would not start were right on point. However I was wrong and only the Net and Firewall qubes had issue, not the USB. I’ve since set the Net and FW qubes to manual startup while further testing occurs.

Enjoy the time, and have a wonderful weekend!

Klaus

3 Likes