I’ve spent a week…probably 20-30 hours on trying to get my wireless driver working on my new Dell Inspiron 3520 with a brand new Qubes install. Install went fine except for the driver. I’ve followed the GitHub - tomaspinho/rtl8821ce instructions and any other mod that I’ve read on dozens of threads. $200 bucks to anyone who can walk me through over the phone to get this driver installed.
What goes wrong? Normally I do USB tethering to the PC and then download the necessary packages into a template or standalone Debian VM.
I’d try making sys-net a standalone Debian VM with the kernel provided by the VM. Don’t include the wireless device. Then build the driver. After it’s installed add the device back. Don’t forget to set VM type as HVM and check provides network access when making the standalone.
Actually, you can try following what this user suggested
I’ve done all of that…5x…isn’t working. Either I’m doing something wrong or there is one little thing that someone else would see that I’m missing. Hence, the cash reward.
Searching the forum, I spot this (very short) desciption of possible steps to get a RTL8821ce working:
Since I don’t have the hardware, it’s not something I’ve tried and not something I can test myself … :-/
What is the actual error?
When trying to start sys-net, Failed to Start. Cannot connect to qrexec agent. Log shows Kernel Panic. If I remove RTL8821ce as a device from sys-net, starts fine, but not wireless networking. If I install GitHub - tomaspinho/rtl8821ce, everything seems to do well but after I reboot I do not have any wireless connection. I can’t even tell if Tom’s driver is loading. I’ve blacklist rtw8821 as many suggest. USB tethering to my phone works great. But I can’t get the rtl8821ce driver to work.
Here’s my exact repo steps:
New install
Try to start sys-net, fails, remove rtl8821ce as a device, restart, starts
Start sys-usb, do usb tethering to phone, get Internet
Sudo apt-get update
Sudo apt install -y dkms git
Git clone https://github/com/tomaspinho/rtl8821ce.git
sudo apt install bc module-assistant build-essential dkms
sudo m-a prepare
Disconnect usb tethering
Sudo Chmod +x dkms-install.sh
Sudo ./dkms-install.sh
Sudo modprobe 8821ce
And supposedly at this point I’m supposed to see a wireless network, but it never appears. Nothing I’ve tried has helped.
Other Things tried:
blacklisted other driver, by creating file /etc/modprobe.d/blacklist.conf
with content blacklist rtw88_8821ce
sudo $EDITOR /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT=“quiet splash pcie_aspm=off”
Sudo update-grub
Tried changing sys-net qube to PV and PVH from HVM
Set init-memory to 825MB from 425M
(when each of these didn’t work, I reset back to the defaults so I wasn’t adding too many changes during the troubleshooting process)
Tomas…the creator of the rtl8821ce github driver is helping me to troubleshoot. He thinks that perhaps the driver should be installed in dom0 instead of sys-net. He’s not a qubes guy and I’m brand new…so is there any reason why installing the driver there would make more sense than sys-net?
that would not make any sense and doing so would significantly compromise the security and the entire point of qubes os; you are not meant to have dom0 as a network facing service it is not configured to provide networks to the rest of the system anyways and there is no easy way to make it do so so even if you got it to install and work within dom0 it would be useless because dom0 does not provide networks to your other vms and there is no available option to make it do so! If you are running a debian-12-xfce or fedora-40-xfce install it is likely you have all the default qubes pkgs you need in your sys-net vm however if you are not I would check out the minimal pkgs page of the docs and make sure you have all the pkgs downloaded which are required for a working sys-net qube. Your solution will have to be applied to your sys-net template if you are applying the install steps to an appvm it is unlikely they will persist after restarting sys-net unless they are installed to your user directories. If you have not already turn off dynamic memory balancing through qube-settings for the sys-net vm as it is known to disrupt some hardware devices; Happy hunting and good luck.
Thanks for your reply. That’s what I thought.
Dynamic memory balancing not enabled
Not sure why a brand new Qubes install would not have the ‘minimal pkgs’ installed or even how to tell. sys-net works great with tethered USB to the Internet. The only thing that seems not to be working is the rtl8821ce wireless driver…and the Internet seems to be full of people complaining about Qubes and this one driver.
You have to shutdown the qube and then add back the device. Is sys-net an AppVM or StandaloneVM? It should be a StandaloneVM, otherwise the changes won’t be saved.
lspci and lsusb are the first things to do to see if fancy hardware is available.
Sometimes laptops are configured to block certain devices for “security reasons”.
Please first use kali live from an usb stick to see, if the devices are there.
If yes, try qubes-os to see if they are still there or some madness has taken them to some obscure service vm because the device is “evil” like USB
Then if you found the thief of your device, manage the devices in the qubes-manager to free the pci-device nic and give it to the net-vm.
donate the 200 bucks to chabad
I did exactly that…my repo steps are in this thread. The VM is already HVM, but I tried PV and PVH. It’s HVM today. If I add the RTL8821CE device back in sys-net refuses to start using the same original error that it cannot connect to the qrexec agent, just like I started with. When installing the alternate Tomas driver I don’t believe you add the device back in.
This may be the issue. It’s an AppVM. I’ll try the standalone one. I’m hoping this is it. Thank you.
I am not at the qubes box right now to look at sys-net. But sys-net owns the PCI device NIC so it should be set in the settings of the VM. An AFIK it is an app-vm with proper pci pass through settings.
You IOMMU blocks your VM from HW access if not explicitly enabled in the settings.
Remember the good old days of the “firewire debugger” that could read 4GB of PCI address space?
This is why you want an IOMMU with qubes, and why qubes requires you to have an IOMMU. With old metal qubes can only be used with servers or workstations which were the first to feature an IOMMU…
In my attempt to create a Standalone VM, I think I used qvm-create to clone debian-12-xfce to a new sys-net-perm qube. I’ve set it to be its own Provides Network. Under Settings, Basic, General, the type says TemplateVM and not Standalone VM. Is that right?
I would prefer a StandaloneVM, but a TemplateVM should work. I believe you would have to install the DKMS module in the template (which in this case seems to be the sys-net-perm qube) and then create another AppVM that uses that qube as the template, which has to have the drivers attached and provides network access checked, not the template)
If I were doing it, I would delete the sys-net-perm qube and recreate it as a StandaloneVM (add --standalone or --class StandaloneVM when using qvm-create, or just select the type in the Create New Qube interface)
Once it’s StandaloneVM, the steps you’ve tried before should work this time. Let me know if it works.
At this point it would be advisable to inspect the journal of the machine; maybe run sudo journalctl -f in a separate window.
There are two alternatives for the hardware, maybe less frustrating:
- If the machine has an Ethernet port, you might consider getting a WLAN repeater with an Ethernet port, so that you can connect the Ethernets with a cable, and the repeater will do the WLAN job. I did that in the past with my Realtech USB WLAN adapter on the PC (that needed a special driver apart from the USB woes in Qubes OS).
- In most laptops (I don’t know for the Dell) the WLAN adapters are stamp-size cards that can be replaced. Maybe with some help the easiest way is to replace the adapter with one that works out of the box. I’m writing this on a Lenovo laptop that has a
00:06.0 Network controller: Intel Corporation Raptor Lake-S PCH CNVi WiFi (rev 11)
Subsystem: Intel Corporation WiFi 6E AX211 160MHz
Physical Slot: 6
Flags: bus master, fast devsel, latency 0, IRQ 42
Memory at f2000000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [c8] Power Management version 3
Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [40] Express Root Complex Integrated Endpoint, IntMsgNum 0
Capabilities: [80] MSI-X: Enable+ Count=16 Masked-
Kernel driver in use: iwlwifi
Kernel modules: iwlwifi
working “out of the box” in fedora-40-xfce-based sys-net.
I just had another thought:
During installation the network adapter(s) are assigned to sys-net, but if the adapter is not recognized, it may not be assigned. Did you check the available devices in sys-net settings? If there is no device listed, it cannot work, whatever driver you are using. Be warned: Why trying to add the missing device you can easily make the system unusable if you assign the wrong device (taking it away from Dom0).
Well, you can make the software match the hardware (after buying, that’s what you are trying), or make the hardware match the software (before buying the hardware).
As mentioned I had bought a TP-LINK USB WLAN adapter where the box said it works on Linux. When trying I found out that I have to download and compile the driver myself. As a matter of fact it didn’t even compile as it was written for a much older kernel. Asking TP-LINK support about it, they referred me to Realtech as it’s their chip they are using… You get the story… Meanwhile there exists an experimental driver that is not yet part of the standard distributions…
Typically that means sys-netis not working; maybe it hangs, or it crashed. Try to get the logs to see what actually happens.
Finally on the advice of @tumble: It’s too late now, but it would have been wise to clone the original sys-net to have a backup you can always revert to when the current experiment goes wrong (and you are still able to use the qubes manager).
While it’s tempting to try a lot of different things sequentially until “it works”, it’s more advisable to restart with a clean state applying only one minimal change until it works. So at the end you know what was the problem actually.
Unfortunately one can find a lot of “solutions” in the Internet that contain unnecessary or even harmful steps…