-
-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
kernel-devel needs tools/objtool/objtool to compile out-of-tree kernel modules #3835
Comments
First of all, kernel provided from dom0 already have u2mfn module, you don't need compile it. I know there is automatic dkms service trying to build this module at VM startup. But we've disabled it recently (QubesOS/qubes-core-agent-linux@76649d8), exactly for this reason - it's going to be part of the nearest update. @andrewdavidwong I think we should deprecate support of out of tree modules if using kernel from dom0. Kernel installed in VM works sufficiently ok for HVM (where such modules have the most use cases - drivers for PCI devices). We can't remove it completely yet, because of missing PVH support... |
How about in the Developer FAQ? |
Not convinced if deprecating it at this point is a good idea. If you look at the last Linux versions we always had some patches which fixed important issues. So by using distro kernels people will have it much easier to build OOT modules but then need to track Xen related kernel fixes. Of corse I try to always push fixes we track down to stable and 4.17 hopefully will look better (didn't tried the rc yet for new regressions) so this should get better, but not convinced that it's good enough yet. I will have a look if I see an easy fix for the build problems. |
Would it not be sufficient to allow the kernel from dom0 to be installed in a TemplateVM so that you can build modules for it? That would require a separate package though. It also doesn't help currently that dom0 is based on a different fedora release than the new templates. I understand that using HVM would have a higher memory requirement (perhaps this is incorrect) so for things like VPN (wireguard) I would like to avoid it. Edit: To get objtool to build, check out the qubes-linux-kernel repository and run |
@vladimir-lu I'm stuck in a similar place. I was wondering if you could expand on your previous comment? How does this work? |
This is fixed with QubesOS/qubes-linux-kernel@0a7a0df |
Qubes OS version:
Qubes release 4.0 (R4.0)
Affected component(s):
kernel-devel
Steps to reproduce the behavior:
dom0 kernel version is 4.14.18-1.pvops.qubes
Install kernel-devel
sudo qubes-dom0-udpate kernel-devel
Boot the fedora-26 template vm with the same kernel
Install qubes-kernel-vm-support
sudo dnf install qubes-kernel-vm-support
Build the module
sudo dkms build -m u2mfn -v 4.0.17
Expected behavior:
Successful building of the module.
Actual behavior:
Kernel preparation unnecessary for this kernel. Skipping...
Building module:
cleaning build area...
make -j2 KERNELRELEASE=4.14.18-1.pvops.qubes.x86_64 -C /lib/modules/4.14.18-1.pvops.qubes.x86_64/build M=/var/lib/dkms/u2mfn/4.0.17/build...(bad exit status: 2)
Error! Bad return status for module build on kernel: 4.14.18-1.pvops.qubes.x86_64 (x86_64)
DKMS make.log for u2mfn-4.0.17 for kernel 4.14.18-1.pvops.qubes.x86_64 (x86_64)
Fri Apr 20 13:21:39 CEST 2018
make: Entering directory '/usr/lib/modules/4.14.18-1.pvops.qubes.x86_64/build'
make[1]: *** No rule to make target 'tools/objtool/objtool', needed by '/var/lib/dkms/u2mfn/4.0.17/build/u2mfn.o'. Stop.
make[1]: *** Waiting for unfinished jobs....
AR /var/lib/dkms/u2mfn/4.0.17/build/built-in.o
make: *** [Makefile:1507: module/var/lib/dkms/u2mfn/4.0.17/build] Error 2
make: Leaving directory '/usr/lib/modules/4.14.18-1.pvops.qubes.x86_64/build'
General notes:
Similar bugs have been spotted on other distributions.
The reason is that "objtool needs to be included to sucessfully
build all out-of-tree kernel modules, when kernel code include metadata
are generated by this tool (for example when CONFIG_STACK_VALIDATION /
CONFIG_UNWINDER_ORC enabled - ORC is enabled by default in 4.14.9+)."
details can be found in the following link from Debian bug report.
Related issues:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833500
The text was updated successfully, but these errors were encountered: