What questions belong to Fedora, xcfe or Qubes OS specific?

When I have a question, should I search “Fedora XXX”, “xcfe XXX” or “Qubes OS XXX”. Fedora and xcfe have more data on the Internet than Qubes OS because they have more users, so it’s easier to search with them.

Such as

Normally it is done by install scripts from nvidia package, but unfortunately it isn’t compatible with Qubes

in Install Nvidia driver

The answer to this comes intuitively for veteran Qubes OS users, but it can be difficult to concisely explain to a third party, because it isn’t really something a veteran has to do that often…

But I’ll do my best :stuck_out_tongue:


  • If you can determine where XFCE and Fedora slot into Qubes OS, then that’s your answer.

    • You have already separated your understanding into the different components of Qubes OS, which is way more than many users do (especially the newer ones), so you’re already most of the way there :slight_smile:
  • XFCE runs in dom0, and dom0 only

    • Run xfce4-panel inside an AppVM and see what happens. I’m having trouble explaining it accurately with words :stuck_out_tongue:
    • Yes, you can run XFCE stuff inside AppVMs, but they will not talk to the dom0 XFCE, which I’m guessing is what you want.
    • Just for completeness, there is plans and progress made into getting XFCE and the entire GUI stack out of dom0 and into its own dedicated VM called sys-gui. It’s “in the oven baking”, but it’s not quite “golden-brown” yet, but give it time :wink:
  • AppVMs can “kind of” interact with the dom0 XFCE in some ways

    • nm-applet runs in sys-net but shows up in the dom0 XFCE panel
    • If you’ve ever run deluge or vlc in an AppVM, you can see that their panel icon shows up in the dom0 XFCE panel
  • Any advice you take from anywhere else needs to be “qubified” (patent pending on that term :wink:) before it’ll work as intended

    • You have to figure out where exactly to execute their instructions
    • You have to figure out what parts of your system their instructions will interact with, and make sure that they’re reachable from where you execute them.
    • A command run inside a VM that is designed to interact with something in dom0 will usually fail, unless dom0 has specifically been told to allow it
  • All firmware/drivers need to be installed in the place that the hardware will be used

    • If your hardware only ever stays in dom0, then it’ll need to be installed in dom0 (although, before you do this, you should probably ask yourself if your hardware actually needs to stay in dom0 in the first place :stuck_out_tongue: )
    • If you use pciback to pass your hardware into a VM (like 99% of hardware that you’d ever need to install additional firmware/drivers for), then you’ll need to install it into that VM

@Rhys-Hussain Does this kind of make sense?

From this, I get, xcfe only manages panel(window) of AppVM, if want want to adjust panel of AppVM, look at XCFE doc.

It will be more helpful if you can indicate what hardwares and instructions will interact with dom0 by default.

The point I was trying to make was that if you run anything XFCE-related inside an AppVM, it’ll run, but it will be wholly contained inside that AppVM, and won’t interact with anything outside that AppVM (like the dom0 XFCE components).

So any changes you made in that wouldn’t change what the dom0 XFCE looked like, because they’re completely separate and don’t talk to each other.

I was trying to make what I wrote apply to as many situations as possible, not just yours (so it could help anyone else who happen to read it). But you’re right. That would definitely be more helpful.

Ok, here goes.

Things that need to be installed in Dom0

  • Anything involving the BIOS will need to be done in dom0.

    • flashrom
    • BIOS updates
    • I would be extremely concerned if an AppVM could interact with the BIOS by default…
  • Anything involving the primary framebuffer display/monitor

    • i915, amdgpu, nouveau, and whatever proprietary stuff nVIDIA cards need to run properly
  • Anything involving the TPM, or any other chips on your motherboard that Qubes OS dom0 would use to verify system integrity at boot

  • Anything involving any sort of hardware security chips to verify system integrity at boot

    • YubiKey firmware
    • There are other examples, but I just can’t think of any prominent ones right now. I will edit this post when I think of any.

Things that can be installed in system VMs instead of dom0

  • Wifi drivers
    • They’d go in sys-net
  • USB peripheral firmware
    • USB mouse keyboard config tools (RGB, button/key customisation, etc.)
    • They’d go in sys-usb (or whatever VM you had your USB controllers in)
  • GPU drivers/firmware for non-primary GPUs
    • If you intend to do GPU passthrough, dom0 would pass the entire GPU into the VM, and the VM would do the “driving”, hence the drivers would need to be in the VM

To relate this to your situation of installing nVIDIA drivers, they’d need to be installed in the same place as your GPU. Most likely, your GPU would stay in dom0, therefore, it would need to be installed in dom0.

I’m sorry, I don’t have any nVIDIA hardware, so I don’t have any first-hand experience doing what you’re trying to do.

Being a Linux user of more than two decades, I have been conditioned to “avoid it like the plague” :stuck_out_tongue_winking_eye:

But these threads should be able to at least point you in the right direction:

I hope this helps :slight_smile:

The Nvidia I mentioned was just an example, you don’t need to care it here. I want a general guide for many people too, then people can find a direction if they have problem.

1 Like

Most problems that do not happen when using Ubuntu/Fedora is Qubes specific, even if it is only problem combining fedora and/or xfce and/or linux kernel and/or lvm and/or systemd and/or xen and/or python hacks.

Even if that problem is not technically Qubes OS specific, it is usually a problem that many Qubes OS users will also encounter. For example, normal linux user will not commonly play with lvm and xen and dummy x server unless it is a Qubes OS user. Therefore in most of the time, it should be OK to ask out the questions as if it is Qubes OS specific.

Nevertheless, if one want to approach the problem himself, any Qubes OS problem should be factored into a normal linux problem, whether it is related to fedora distro, xfce window manager, or lvm file system, xen hypervisor, kernel driver, or even a userspace program malfunction. A problem that is technically Qubes OS specific will be solved with methods requiring general linux skills.