I’m trying to achieve my goal from here.
One of the very first steps is to install necessary packages:
Option for Debian, Kali, and Raspberry Pi Desktop (x86)
sudo apt install -y linux-headers-$(uname -r) build-essential bc dkms git libelf-dev rfkill iw
But, for the linux-headers I’m getting the error
E: Unable to locate package linux-headers-6.1.1-1.fc32.qubes.x86_64
How can I obtain/build it?
For .qubes kernels, dom0 already provides the headers to the VM at the conventional place /usr/lib/modules/$(uname -r)/build without having to install a separate kernel headers package.
Thanks @rustybird. I am aware of the files both in dom0 and VMs, as wel as in /usr/src folders, but since I don’t have experience with this at all, I am not nearly sure how can I use your info to overcome system complaint above.
To me, it looks like a mix of a Fedora build kernel (fc32.qubes) and Debian installer (apt install). I don’t know if the Qubes testing repos provide those packages (?) … :-/
It should be enough to omit linux-headers-$(uname -r) from the command you posted, changing it to:
sudo apt install -y build-essential bc dkms git libelf-dev rfkill iw
SSBnb3QgeW91IQ==
Ah, thanks, I saw it meanwhile:
sudo make dkms_install
mkdir: created directory '/usr/src/8812au-5.6.4.2_35491.20191025'
cp -r * /usr/src/8812au-5.6.4.2_35491.20191025
dkms add -m 8812au -v 5.6.4.2_35491.20191025
Creating symlink /var/lib/dkms/8812au/5.6.4.2_35491.20191025/source ->
/usr/src/8812au-5.6.4.2_35491.20191025
DKMS: add completed.
dkms build -m 8812au -v 5.6.4.2_35491.20191025
Kernel preparation unnecessary for this kernel. Skipping...
Building module:
cleaning build area...
'make' -j2 KVER=6.1.1-1.fc32.qubes.x86_64 KSRC=/lib/modules/6.1.1-1.fc32.qubes.x86_64/build...(bad exit status: 2)
Error! Bad return status for module build on kernel: 6.1.1-1.fc32.qubes.x86_64 (x86_64)
Consult /var/lib/dkms/8812au/5.6.4.2_35491.20191025/build/make.log for more information.
make: *** [Makefile:2318: dkms_install] Error 10
So, again at the beginning of my saga with dkms…
The kernel was built by: gcc (GCC) 10.3.1 20210422 (Red Hat 10.3.1-1)
You are using: gcc (GCC) 12.2.1 20221121 (Red Hat 12.2.1-4)
The problem is that even if I use gcc v12.x, but under kernel 5.15.74. it’ll build those drivers, so how it is even related what gcc version is, when it is obvious it’s about the kernel - under one it’ll compile drivers, on another it won’t, both with the same gcc version (12.x in this case)…
I think it has something with the fact that some kernels are not -latest, and will be listed under rpm -qa kernel, while -latest will be listed only with rpm -qa kernel\* | sort -V (for example)
Thanks to @ChrisA and @xn0px90 on their opinions (it happens both in Debian and Fedora templates) too. Please see my message above.
SSBnb3QgeW91IQ==
Oh man, I was too fixated on your immediate question of where to get the kernel headers. Actually using DKMS with a dom0-provided kernel seems like it would be quite painful, because of the mismatched build environment (Qubes R4.1 kernels are built in Fedora 32) and probably a complete lack of integration with the distribution’s DKMS tooling too.
I’d switch the VM (the one that will eventually be running your custom kernel module) to a distribution-provided kernel like unman suggested - theoretically this should work for all virtualization modes, distributions, and VM types? - and then figure out DKMS in that VM('s TemplateVM).
Honestly though: If it’s just for some Wi-Fi dongle, your time might be better spent looking for a different one that simply works (at least with a recent kernel).
Well, I wanted to be fixated on this, since on different topics I already tried everything else. This was last to try using Qubes kernel-latests and or >=v6.x to build drivers using dkms. So, thanks and it was very valuable for me.
I did, actually. Unfortunately it doesn’t work with Fedora, at least for me. And my whole system is based on Fedora (except cacher) because the logic was if dom0 is based on fedora, everything else would work smoother with it too. It works with Debian. though.
Well, I specifically choose it because it is claimed to work the best with Kali.
Both in debian-11-minimal and fedora-37-minimal
$ cat /proc/version (same kernel with uname -a)
Linux version 6.1.1-1.fc32.qubes.x86_64 (mockbuild@8dbe2b65ccd44a1eb379dbb612d8d308) (gcc (GCC) 10.3.1 20210422 (Red Hat 10.3.1-1), GNU ld version 2.34-6.fc32) #1 SMP PREEMPT_DYNAMIC Tue Dec 27 18:08:59 CET 2022
Some things never seem to change, such as Wi-Fi hardware being presumed broken unless there’s a statement as specific as “works with unpatched mainline kernel version x.y.z, linux-firmware version YYYYMMDD” and ideally you’re pointing a gun at the person making this statement, pending verification.