Kernel modules are stored on the root volume, not on the private volume. This volume does not persist across AppVM reboots, which is causing the behavior you are describing.
There are a few different solutions to this problem:
- Use hardware that does not require third-party drivers. This is the most secure solution, but it is likely impractical in your case.
- Use the
bind-dirsfeature of Qubes OS so that the drivers are installed to the private volume instead.
- Use a StandaloneVM for
sys-net. This is the simplest solution that is still secure.
I;m sorry but can you go into more detail? This is still just a little hard to understand. Can you tell me how to do that?
@adw would you be willing to try explaining?
jon-bit, Demi is saying that you have three options. We can’t tell you which of the three options to choose, because that’s up to you. However, we can try to help.
First of all, can you get new hardware? If you can obtain a better-supported computer, then do that. That’s the easiest fix.
Can’t get a new computer? Your next best option is probably to make
sys-net a StandaloneVM. What does that mean? Read this page to understand StandaloneVMs and how to create them:
Now that you’ve created a StandaloneVM, you need to make it so that it’ll function as
sys-net. Go into the Qube Settings for your current
sys-net, go to the Devices tab, and write down which devices are selected on the right. Then go into the settings for the new StandaloneVM and assign those same devices. Also, go to the Advanced tab and make sure the virtualization mode is set to HVM. Also, go to the Services tab and add the
clocksync service. Basically, make the settings of the new StandaloneVM match those of your current
sys-net, as it’s going to replace it.
Now that I’ve written all of this, I don’t know whether it’ll actually be easier for you than the
bind-dirs option. If you want to read more about that option, here’s the documentation:
I’m sure others in this forum will be able to explain this better than I have and assist you further.