#19644 closed defect (fixed)
Linux kernel version: 5.8 - we need changes (fixed in 6.1.14)
Reported by: | Frank Batschulat (Oracle) | Owned by: | Frank Batschulat (Oracle) |
---|---|---|---|
Component: | other | Version: | VirtualBox 6.1.10 |
Keywords: | linux kernel 5.8 | Cc: | |
Guest type: | Linux | Host type: | Linux |
Description
From: "Larry Finger" <> To: vbox-dev@… Subject: [vbox-dev] Problem with kernel 5.8 Date: Fri, 05 Jun 2020 23:39:08 +0200
In a little over one week, Linus will release Kernel 5.8.0-rc1. Shortly thereafter, openSUSE Tumbleweed will start builds using that kernel. Unless I have patched our copy of the code for the VB kernel modules, my mailbox will be flooded with build failure messages.
Thus far, I have found two incompatibilities with the 5.8 APIs. The first was the removal of get_vm_area(). This one can be trivially replaced with get_vm_area_caller(), which has one additional argument that is always "builtin_return_address(0)."
A second API change is more complicated, and above my understanding. In the associated patch entitled "mm: only allow page table mappings for built-in zsmalloc", symbols map_vm_area() and unmap_kernel_range() are no longer exported. The first of these are used in this snippet found in src/vboxdrv/r0drv/linux/alloc-r0drv-linux.c:
if (iPage == cPages) { /* * Map the pages. * * Not entirely sure we really need to set nr_pages and pages here, but * they provide a very convenient place for storing something we need * in the free function, if nothing else... */ # if LINUX_VERSION_CODE < KERNEL_VERSION(3, 17, 0) struct page **papPagesIterator = papPages; # endif pVmArea->nr_pages = cPages; pVmArea->pages = papPages; if (!map_vm_area(pVmArea, PAGE_KERNEL_EXEC, # if LINUX_VERSION_CODE < KERNEL_VERSION(3, 17, 0) &papPagesIterator # else papPages # endif )) { PRTMEMLNXHDREX pHdrEx = (PRTMEMLNXHDREX)pVmArea->addr; pHdrEx->pVmArea = pVmArea; pHdrEx->pvDummy = NULL; return &pHdrEx->Hdr; } /* bail out */ # if LINUX_VERSION_CODE < KERNEL_VERSION(3, 17, 0) pVmArea->nr_pages = papPagesIterator - papPages; # endif }
I think the code could use vm_map_ram() to map the papPages array directly, but I would appreciate any help the developers could provide.
Thanks,
Larry
Attachments (16)
Change History (74)
comment:1 by , 4 years ago
Keywords: | linux kernel 5.8 added |
---|---|
Owner: | set to |
Status: | new → accepted |
comment:3 by , 4 years ago
The situation got worse. In another patch,
__get_vm_area_caller()
is no longer exported. At this point, I see no way to map an area of VM short of recreating all the code used in the kernel, and that runs into all kinds of interactions with static variables used by the kernel.
Clearly, the trend is to prevent external modules from getting any control of virtual memory mappings. It will likely be required to rewrite vboxdrv and submit it for inclusion in the kernel. The vboxnet* modules will probably be OK out of the kernel.
by , 4 years ago
Attachment: | fixes_for_mm_struct.patch added |
---|
Apply fixes needed for kernel 5.8 difference in struct mm_struct
by , 4 years ago
Attachment: | fixes_for_changes_in_cpu_tlbstate.patch added |
---|
Fixes associated with hiding of cputlbstate
by , 4 years ago
Attachment: | local_patches added |
---|
Changes needed for kernel 5.8 for patch to module_memory to work
comment:4 by , 4 years ago
A few days before the expected release of kernel 5.8.0-rc1, there are 3 areas that have changed since 5.7.0. The first of these is that In struct mm_struct, member mmap_sem is renamed to mmap_lock. That change is straight-forward and the fix is in patch file fixes_for_mm_struct.patch. A second simple patch handles that the structure cpu_tblstate is now hidden Patch fixes_for_changes_in_cpu_tlbstate.patch handles this. The third kernel change is much more problematic. Kernel routine get_vm_area() was first changed to get_vm_area_caller(), and then the latter routine was no longer exported. In addition, routine map_vm_area() has been removed. I do not have a fix for this. At first it seemed that reverting to the method used before kernel 2.6.13 would work by not defining RTMEMALLOC_EXEC_VM_AREA and using RTMEMALLOC_EXEC_HEAP instead. Unfortunately, this code fails to allocate the memory correctly, and VMs fail to start. I have been unable to fix that problem. My work-around is in file fixes_for_module_memory.patch; however, this change requires that 2 additional exports be added to the kernel at least until the problem with using RTMEMALLOC_EXEC_HEAP is fixed. The patch for the kernel is shown in attachment local_patches.
comment:5 by , 4 years ago
I have been unable to find a solution that does NOT require modifying the kernel. From what I see, the kernel developers have effectively blocked all access to allocation of executable memory other than through the KVM mechanism.
comment:7 by , 4 years ago
Any news here? Kernel 5.8.0 will be out in approximately 3 weeks. At that point, every host trying to run that kernel will break. I have been unable to find a method of allocating executable memory that will work with vboxdrv.
comment:8 by , 4 years ago
Actually I applied the "local_patches" patch to the vanilla 5.8-rc5 kernel and the 3 "fixes-for-*" patches to VB 6.0.10-138449-Linux_amd64. Building that kernel and vboxdrv went without a hitch. Running a non-guest-additions guest seems to be OK.
However the rc3 and rc5 kernels that I tested with have overlayfs/squasfs problems. I do not think these problems are related to VB.
@lwfinger: The in-tree rtw-8723de driver (which triggered me to test things) seems OK.
:D
comment:9 by , 4 years ago
I applied the "local_patches" patch to a vanilla 5.8-rc6 kernel and the 3 "fixes-for-*" patches to VB 6.0.12-139181-Linux_amd64 and 6.1.13-139358-Linux_amd64. Building that kernel and both vboxdrv's went without a hitch. Running non-guest-additions guests shows no anomalies.
The squashfs problem I mentioned above is resolved by rc6.
It is likely that the kernel 5.8 release is only some 2 weeks away. I am curious how patching that kernel for VB will be implemented or can be circumvented.
comment:10 by , 4 years ago
In VB 6.1.13-139554 as well as in VB 6.1.97-139549 I see that the kernel 5.8 support is being worked on -- not all "fixes-for-*" patches are applicable anymore. Building the vboxdrv's either fails or seems to be ok, but then running it fails because of incompatibilities.
:D
comment:11 by , 4 years ago
I tested VB 6.1.13-139679 (no "fixes-for-*") against kernel 5.8-rc7: Building the vboxdrv fails with:
/tmp/vbox.0/linux/SUPDrv-linux.c: In function ‘supdrvOSChangeCR4’: /tmp/vbox.0/linux/SUPDrv-linux.c:760:38: error: ‘cpu_tlbstate’ undeclared (first use in this function); did you mean ‘cpuhp_state’?
I also tested VB 6.1.97-139665 (no "fixes-for-*") against kernel 5.8-rc7: Building the vboxdrv succeeds but running it fails with:
Failed to open a session for the virtual machine Burdi01z97. The version of the device registration structure is unknown to this VBox version. Either mixing incompatible versions or the structure isn't correctly initialized. (VERR_PDM_UNKNOWN_DEVREG_VERSION). Result Code: NS_ERROR_FAILURE (0x80004005) Component: ConsoleWrap Interface: IConsole {872da645-4a9b-1727-bee2-5585105b9eed}
comment:12 by , 4 years ago
Well, I can confirm that the version VirtualBox-6.1.97-139689-Linux_amd64 runs just fine with Kernel 5.8_RC7 on Ubuntu MATE 20.04
Host and guest OS were both Ubuntu MATE 20.04 64-bit.
Thanks guys :)
comment:13 by , 4 years ago
Over here *1) running VB 6.1.97-139689 fails with the same error as 6.1.97-139665 did (see my previous post).
*1) Slackware Current64, gcc 9.3.0, kernel 5.8-rc7 downloaded from https://www.kernel.org/, no patches applied, configured and built by me.
To my very surprise building and running VB 6.1.97-139689 succeeded on my Xubuntu 20.04 *2).
*2) Linux riposo 5.8.0-050800rc7-generic #202007262231 SMP Sun Jul 26 22:33:51 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux downloaded from https://kernel.ubuntu.com/~kernel-ppa/mainline/
by , 4 years ago
VBox.log - VB 6.1.97-139689 against kernel 5.7.12-burdi64
comment:14 by , 4 years ago
Actually I found that VB 6.1.97-139689 fails with the same error against kernel 5.7.12, whereas VB 6.0.12-139181 runs OK against that kernel.
Provided the VBox.log in case someone would want to see it.
comment:15 by , 4 years ago
I cloned Xubuntu's kernel 5.8.0-050800rc7-generic to this Slackware Current64 installation.
Running VB 6.1.97-139689 fails with exactly the same error against this kernel.
Possibly the fact that this is Slackware, so e.g. without systemd is relevant here...
:D
comment:16 by , 4 years ago
Kernel 5.8 released! Success with VB 6.1.97-139689 and Extention Pack 6.1.97-139662[[BR]] Thank you! Dick :D
follow-up: 18 comment:17 by , 4 years ago
Where can I find VB 6.1.97-139689 and Extention Pack 6.1.97-139662?
comment:18 by , 4 years ago
Replying to matthewls:
Where can I find VB 6.1.97-139689 and Extention Pack 6.1.97-139662?
https://www.virtualbox.org/wiki/Testbuilds Under the Development snapshots section.
comment:19 by , 4 years ago
Thanks. Same problem as before with kernel 5.7.12 and 5.8.0. Install works, VMs crash on start with
The version of the device registration structure is unknown to this VBox version. Either mixing incompatible versions or the structure isn't correctly initialized. (VERR_PDM_UNKNOWN_DEVREG_VERSION).
Result Code: NS_ERROR_FAILURE (0x80004005) Component: ConsoleWrap Interface: IConsole {872da645-4a9b-1727-bee2-5585105b9eed}
comment:20 by , 4 years ago
The last VB version that can run VMs using kernel 5.7.12. is Version 6.1.13 r139554 (Qt5.6.1)
No VBox version I've tried works with kernel 5.8. It's likely the host modules supported by Arch/Manjaro aren't up to date yet.
comment:21 by , 4 years ago
Updated linux58-virtualbox-host-module fixes r139554. Will test if newer VBox versions work as well.
comment:22 by , 4 years ago
Nope, newer versions still don't run VMs, bc the vbox host module for manjaro targets VB 6.12
comment:24 by , 4 years ago
Replying to LocutusOfBorg:
I'm adding the last trivial patch needed for kernel 5.8
fencing linux/vermagic.h is already in the trunk gate.
comment:25 by , 4 years ago
Stock kernel 5.8.1 on Slackware Current64:
-- VirtualBox-6.1.97-139787-Linux_amd64.run with Oracle_VM_VirtualBox_Extension_Pack-6.1.97-139662.vbox-extpack: OK
-- VirtualBox-6.1.13-139853-Linux_amd64.run with Oracle_VM_VirtualBox_Extension_Pack-6.1.13-139853.vbox-extpack: OK
:D
comment:26 by , 4 years ago
5.8.1-2-MANJARO, Version 6.1.13 r139853 (Qt5.6.1), Oracle_VM_VirtualBox_Extension_Pack-6.1.13-139853.vbox-extpack: All work fine.
Earlier versions stopped working.
comment:27 by , 4 years ago
Hopefully not a thread hijack, but CentOS 7 latest with kernel-ml (aka kernel 5.8.x at this time) does not build modules with VirtualBox-6.1-6.1.13_139853_el7-1.x86_64.rpm. No kernel-ml newer that 5.7.8 will build with VB of any current nightly version. "tail" of vbox-setup.log looks like: ./include/asm-generic/bug.h:97:3: note: in expansion of macro ‘WARN_FLAGS’
WARN_FLAGS(BUGFLAG_NO_CUT_HERE | BUGFLAG_TAINT(taint));\
./include/asm-generic/bug.h:129:3: note: in expansion of macro ‘WARN_printf’
WARN_printf(TAINT_WARN, format); \
./include/linux/debug_locks.h:31:4: note: in expansion of macro ‘WARN’
WARN(1, "DEBUG_LOCKS_WARN_ON(%s)", #c); \
./arch/x86/include/asm/desc.h:324:2: note: in expansion of macro ‘DEBUG_LOCKS_WARN_ON’
DEBUG_LOCKS_WARN_ON(preemptible());
cc1: some warnings being treated as errors
make[3]: * tmp/vbox.0/linux/SUPDrv-linux.o Error 1
make[2]: * tmp/vbox.0 Error 2
make[1]: * [sub-make] Error 2
make: * [vboxdrv] Error 2
follow-up: 29 comment:28 by , 4 years ago
Archlinux 5.8 has hit. 5.2.45 testbuild (139677) fails to build modules. make.log contents:
DKMS make.log for vboxhost-5.2.45 for kernel 5.8.1-arch1-1 (x86_64) Sat 15 Aug 2020 12:02:53 AM CDT make: Entering directory '/usr/lib/modules/5.8.1-arch1-1/build' CC [M] /var/lib/dkms/vboxhost/5.2.45/build/vboxnetflt/linux/VBoxNetFlt-linux.o CC [M] /var/lib/dkms/vboxhost/5.2.45/build/vboxdrv/linux/SUPDrv-linux.o In file included from ./include/asm-generic/percpu.h:7, from ./arch/x86/include/asm/percpu.h:556, from ./arch/x86/include/asm/preempt.h:6, from ./include/linux/preempt.h:78, from ./include/linux/spinlock.h:51, from /var/lib/dkms/vboxhost/5.2.45/build/vboxdrv/linux/../SUPDrvInternal.h:76, from /var/lib/dkms/vboxhost/5.2.45/build/vboxdrv/linux/SUPDrv-linux.c:32: /var/lib/dkms/vboxhost/5.2.45/build/vboxdrv/linux/SUPDrv-linux.c: In function ‘supdrvOSChangeCR4’: /var/lib/dkms/vboxhost/5.2.45/build/vboxdrv/linux/SUPDrv-linux.c:759:38: error: ‘cpu_tlbstate’ undeclared (first use in this function); did you mean ‘cpuhp_state’? 759 | RTCCUINTREG uOld = this_cpu_read(cpu_tlbstate.cr4); | ^~~~~~~~~~~~ ./include/linux/percpu-defs.h:318:9: note: in definition of macro ‘__pcpu_size_call_return’ 318 | typeof(variable) pscr_ret__; \ | ^~~~~~~~ /var/lib/dkms/vboxhost/5.2.45/build/vboxdrv/linux/SUPDrv-linux.c:759:24: note: in expansion of macro ‘this_cpu_read’ 759 | RTCCUINTREG uOld = this_cpu_read(cpu_tlbstate.cr4); | ^~~~~~~~~~~~~ /var/lib/dkms/vboxhost/5.2.45/build/vboxdrv/linux/SUPDrv-linux.c:759:38: note: each undeclared identifier is reported only once for each function it appears in 759 | RTCCUINTREG uOld = this_cpu_read(cpu_tlbstate.cr4); | ^~~~~~~~~~~~ ./include/linux/percpu-defs.h:318:9: note: in definition of macro ‘__pcpu_size_call_return’ 318 | typeof(variable) pscr_ret__; \ | ^~~~~~~~ /var/lib/dkms/vboxhost/5.2.45/build/vboxdrv/linux/SUPDrv-linux.c:759:24: note: in expansion of macro ‘this_cpu_read’ 759 | RTCCUINTREG uOld = this_cpu_read(cpu_tlbstate.cr4); | ^~~~~~~~~~~~~ make[2]: *** [scripts/Makefile.build:281: /var/lib/dkms/vboxhost/5.2.45/build/vboxdrv/linux/SUPDrv-linux.o] Error 1 make[1]: *** [scripts/Makefile.build:497: /var/lib/dkms/vboxhost/5.2.45/build/vboxdrv] Error 2 make[1]: *** Waiting for unfinished jobs.... CC [M] /var/lib/dkms/vboxhost/5.2.45/build/vboxnetflt/VBoxNetFlt.o CC [M] /var/lib/dkms/vboxhost/5.2.45/build/vboxnetflt/SUPR0IdcClient.o CC [M] /var/lib/dkms/vboxhost/5.2.45/build/vboxnetflt/SUPR0IdcClientComponent.o CC [M] /var/lib/dkms/vboxhost/5.2.45/build/vboxnetflt/linux/SUPR0IdcClient-linux.o LD [M] /var/lib/dkms/vboxhost/5.2.45/build/vboxnetflt/vboxnetflt.o make: *** [Makefile:1756: /var/lib/dkms/vboxhost/5.2.45/build] Error 2 make: Leaving directory '/usr/lib/modules/5.8.1-arch1-1/build'
comment:29 by , 4 years ago
Replying to drankinatty:
Archlinux 5.8 has hit. 5.2.45 testbuild (139677) fails to build m
5.2.X and 6.0.X are no longer supported.
https://www.virtualbox.org/wiki/Downloads
If you're looking for the latest VirtualBox 6.0 packages, see VirtualBox 6.0 builds. Please also use version 6.0 if you need to run VMs with software virtualization, as this has been discontinued in 6.1. Version 6.0 will remain supported until July 2020. If you're looking for the latest VirtualBox 5.2 packages, see VirtualBox 5.2 builds. Please also use version 5.2 if you still need support for 32-bit hosts, as this has been discontinued in 6.0. Version 5.2 will remain supported until July 2020.
follow-up: 31 comment:30 by , 4 years ago
5.2.44 does not build against Linux 5.8 -- that is why I posted this bug. I don't understand your comment "5.2.X" is no longer supported? That's news to me. I maintain that package for Archlinux through their AUR repository specifically to handle windows guests headless which the 6.X version does not handle well. (a simply "Dir" listing may take 5 minutes for 200 files) 5.2 never had that problem. With the new 5.2.44 less than 2-weeks old -- where did I miss the announcement that 5.2.X was being discontinued? It is critical given the number of headless guests I run.
comment:31 by , 4 years ago
Replying to drankinatty:
5.2.44 does not build against Linux 5.8 -- that is why I posted this bug. I don't understand your comment "5.2.X" is no longer supported? That's news to me. I maintain that package for Archlinux through their AUR repository specifically to handle windows guests headless which the 6.X version does not handle well. (a simply "Dir" listing may take 5 minutes for 200 files) 5.2 never had that problem. With the new 5.2.44 less than 2-weeks old -- where did I miss the announcement that 5.2.X was being discontinued? It is critical given the number of headless guests I run.
As Is aid, see the statement on web page:
https://www.virtualbox.org/wiki/Downloads
5.2.X and 6.0.X are out of support life and are unlikely getting 5.8 support.
What is the bugid of the windows/dir/headless performance problem you mentioned?
comment:32 by , 4 years ago
Why are you excluding old machines without virtualization technology ? We as students need really Virtualbox for running Linux and Windows 7 VMs to practice networking and system administration courses, we don't have money to buy new machines with new CPUs, and most of machines available in our university does not support any virtualization technologies.
We need really support for 6.0 version because with the new 5.8 kernel on Manjaro I got an error while installing the .run file: error: ‘cpu_tlbstate’ undeclared (first use in this function); did you mean ‘cpuhp_state’?
comment:33 by , 4 years ago
Stock kernel 5.8.1 on Slackware Current64:
-- VirtualBox-6.1.13-139930-Linux_amd64.run with Oracle_VM_VirtualBox_Extension_Pack-6.1.13-139930.vbox-extpack: OK
:D
comment:34 by , 4 years ago
5.8-rc1 was released on June 14th and still, after 2 months, no solution for this.
by , 4 years ago
Attachment: | vbox-setup.log-CentOS7-kernel-ml-5.8 added |
---|
CentOS7-kernel-ml-5.8 build fail
follow-up: 36 comment:35 by , 4 years ago
Just posted build log for failed build with most recent VB testbuild VirtualBox-6.1-6.1.13_139930_el7-1.x86_64.rpm
follow-up: 37 comment:36 by , 4 years ago
Replying to pjwelsh:
Just posted build log for failed build with most recent VB testbuild VirtualBox-6.1-6.1.13_139930_el7-1.x86_64.rpm
Posting the build log is not enough, it helps when you actually read it.
https://www.virtualbox.org/attachment/ticket/19644/vbox-setup.log-CentOS7-kernel-ml-5.8
gcc -Wp,-MMD,/tmp/vbox.0/linux/.SUPDrv-linux.o.d -nostdinc -isystem /usr/lib/'''gcc/x86_64-redhat-linux/4.8.5''' ... 14 In file included from ././include/linux/compiler_types.h:68:0, 15 from <command-line>:0: 16 ./include/linux/compiler-gcc.h:15:3: error: #error Sorry, your compiler is too old - please upgrade it. 17 # error Sorry, your compiler is too old - please upgrade it. 18 ^
https://elixir.bootlin.com/linux/v5.8/source/include/linux/compiler-gcc.h
/* https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145 */ #if GCC_VERSION < 40900 # error Sorry, your compiler is too old - please upgrade it. #endif
And you are using: /usr/lib/gcc/x86_64-redhat-linux/4.8.5
follow-up: 38 comment:37 by , 4 years ago
Thank you for replying. That error did strike me as odd as the same system with the same gcc setup will build under the 3.10.x kernel. The compiler is not changing. Yes, the /usr/lib/gcc/x86_64-redhat-linux/4.8.5 is in place on these systems. Why would the "el7" version of VB not be able to use it or think it's too old?
rpm -qf /usr/lib/gcc/x86_64-redhat-linux/4.8.5 gcc-4.8.5-39.el7.x86_64
Replying to fbatschu:
Replying to pjwelsh:
Just posted build log for failed build with most recent VB testbuild VirtualBox-6.1-6.1.13_139930_el7-1.x86_64.rpm
Posting the build log is not enough, it helps when you actually read it.
https://www.virtualbox.org/attachment/ticket/19644/vbox-setup.log-CentOS7-kernel-ml-5.8
gcc -Wp,-MMD,/tmp/vbox.0/linux/.SUPDrv-linux.o.d -nostdinc -isystem /usr/lib/'''gcc/x86_64-redhat-linux/4.8.5''' ... 14 In file included from ././include/linux/compiler_types.h:68:0, 15 from <command-line>:0: 16 ./include/linux/compiler-gcc.h:15:3: error: #error Sorry, your compiler is too old - please upgrade it. 17 # error Sorry, your compiler is too old - please upgrade it. 18 ^https://elixir.bootlin.com/linux/v5.8/source/include/linux/compiler-gcc.h
/* https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145 */ #if GCC_VERSION < 40900 # error Sorry, your compiler is too old - please upgrade it. #endifAnd you are using: /usr/lib/gcc/x86_64-redhat-linux/4.8.5
follow-up: 39 comment:38 by , 4 years ago
Replying to pjwelsh:
Thank you for replying. That error did strike me as odd as the same system with the same gcc setup will build under the 3.10.x kernel. The compiler is not changing. Yes, the /usr/lib/gcc/x86_64-redhat-linux/4.8.5 is in place on these systems. Why would the "el7" version of VB not be able to use it or think it's too old?
Please read my comment carefully. The error message is not from VB, the error message comes from the Linux 5.8 kernel header files. Feel free to discuss this matter further with the Linux kernel community or the CentOS maintainers.
comment:39 by , 4 years ago
Again, thank you for the response. I did not catch the inference of the issue. Thank you for pointing that out directly.
Replying to fbatschu:
Replying to pjwelsh:
Thank you for replying. That error did strike me as odd as the same system with the same gcc setup will build under the 3.10.x kernel. The compiler is not changing. Yes, the /usr/lib/gcc/x86_64-redhat-linux/4.8.5 is in place on these systems. Why would the "el7" version of VB not be able to use it or think it's too old?
Please read my comment carefully. The error message is not from VB, the error message comes from the Linux 5.8 kernel header files. Feel free to discuss this matter further with the Linux kernel community or the CentOS maintainers.
follow-up: 42 comment:40 by , 4 years ago
Stock kernel 5.8.2 on Slackware Current64:
-- VirtualBox-6.1.13-139989-Linux_amd64.run with Oracle_VM_VirtualBox_Extension_Pack-6.1.13-139990.vbox-extpack: OK
:D
comment:41 by , 4 years ago
Is there a release date for this yet? I'm asking because I need to figure out if I am going to have to put in mitigations for 5.8 upgrades on my system or if a release is coming out next week. The workarounds for this are starting to get irritating.
comment:42 by , 4 years ago
Replying to burdi01:
Stock kernel 5.8.2 on Slackware Current64:
-- VirtualBox-6.1.13-139989-Linux_amd64.run with Oracle_VM_VirtualBox_Extension_Pack-6.1.13-139990.vbox-extpack: OK
:D
Confirmed in Archlinux as well with 5.8.2 and with the addition of virtualbox-ext-oracle-6.1.13.139990 (though having split testbuild build versions for virtualbox and the SDK does add a bit of complexity...) Modules build for Linux 5.8.1 and 5.8.2.
follow-up: 51 comment:43 by , 4 years ago
We generally don't communicate any estimated release dates and/or schedules to the public. An update will come in the not too distant future though.
by , 4 years ago
Attachment: | vbox-setup.log added |
---|
/var/log/vbox-setup.log after running /sbin/vboxconfig in F32 with kernel-5.8.4-200.fc32.x86_64
comment:46 by , 4 years ago
I'm running F32 and did not see jvitalii's error. Attached /var/log/vbox-setup.log while running kernel-5.8.4-200.fc32.x86_64 in F32. The kernel modules build in 5.7.17 but not in 5.8.4.
comment:47 by , 4 years ago
The /var/log/vbox-setup.log on Fedora32 produced by dkms during kernel-5.8.4 installation. Mostly the same as @robatino's except for the last few lines.
comment:48 by , 4 years ago
Trying to install VBox in Fedora 32 without success:
# rpm -qa kernel |sort -V |tail -n 1
kernel-5.8.4-200.fc32.x86_64
# uname -r
5.8.4-200.fc32.x86_64
# /usr/lib/virtualbox/vboxdrv.sh setup
vboxdrv.sh: Stopping VirtualBox services.
vboxdrv.sh: Starting VirtualBox services.
vboxdrv.sh: Building VirtualBox kernel modules.
vboxdrv.sh: failed: Look at /var/log/vbox-setup.log to find out what went wrong.
# cat /var/log/vbox-setup.log
Building the main VirtualBox module.
Error building the module:
(...)
make[1]: * * * [Makefile:1756: /tmp/vbox.0] Error 2
make: * * * [ /tmp/vbox.0/Makefile-footer.gmk:117: vboxdrv] Error 2
Log attached.
comment:49 by , 4 years ago
@robatino @Sten @MHamati
based on your compile error logs you all are using a released version of Virtualbox that does not support the 5.8 kernel. ONly the Trunk version with its test builds does so currently.
please stop cluttering this bug with your individual error messages unless you have something new to contribute that is not already mentioned in this bug!
Also post your Virtualbox version corresponding to the failed attempts.
comment:50 by , 4 years ago
@fbatschu We need really support for 6.0 with 5.8 kernel, we use Manjaro stable in our center and we have many old machines that have not any virtualization technology (some old dual core cpus), and we need really virtualbox to help students practice network and administration courses.
comment:51 by , 4 years ago
Replying to pentagonik:
We generally don't communicate any estimated release dates and/or schedules to the public. An update will come in the not too distant future though.
Well, this time would be nice , know if you going release it this week . Or if I should look for alternatives like of use VirtualBox-6.1.13. like in https://build.opensuse.org/package/show/Virtualization/virtualbox
Kernel-5.8.4 was landed on Fedora 32 and very soon on Fedora 31 (stable versions of Fedora)
comment:52 by , 4 years ago
I don't know if you want this bug here, but 6.1.13 testbuilds cause Windows7 Headless guests to BlueScreen when attempting to install or update software. After the UAC screen is shown, and Okay clicked, the entire desktop remains grayed as if the UAC dialog was displayed, about 5 seconds pass and then Wham! Blue Screen and windows crashes back to the VirtualBox 6.1 boot screen and reboots.
It definitely has something to do with "Interactive Terminal Detection". When that is displayed and you click to return BLUE SCREEN- reboot. The Event Viewer logs the crash as a "kernel power" crash.
I can move this to another bug if needed, but I have never seen behavior like this before.
comment:53 by , 4 years ago
Confirming that the newly released VB 6.1.14 works with the 5.8.4 kernel. Thanks!
follow-up: 55 comment:54 by , 4 years ago
Resolution: | → fixed |
---|---|
Status: | accepted → closed |
Summary: | Linux kernel version: 5.8 - we need changes → Linux kernel version: 5.8 - we need changes (fixed in 6.1.14) |
fixed in Virtualbox release 6.1.14
comment:55 by , 4 years ago
Replying to fbatschu:
fixed in Virtualbox release 6.1.14
Such a shame to be fixed only for new version and not for 6.0. You care only for people who have new hardware and not for the common people (especially poor ones) that have already old machines and need them for studying or working.
by , 4 years ago
Attachment: | vb-6.0.24-kernel-5.8-sharefolders.patch added |
---|
Virtualbox 6.0.24 patch 6
comment:56 by , 4 years ago
For 6.0.24, these get it to build. I pulled these from "meta-oe-vboxguestdrivers-Fix-build-with-kernel-5.8.patch" which was for 6.1.x series. These are I suppose against the build tree, but I patched the (6.0.24) files in /usr/share/virtualbox/src/vboxhost/vboxdrv/ that are used to build the kernel modules. For the -p4 patches, I changed to /usr/share/virtualbox/src/vboxhost/vboxdrv/ and applied them like "sudo patch -p4 < ~/path/to/vb-6.0.24-kernel-5.8-p4-1.patch" on each patch. The other patch, "sudo patch -p5 < ~/path/to/vb-6.0.24-kernel-5.8-p5-1.patch". Patch 2 rejects 1 line, but it's a one-line comment saying (paraphrasing) "todo, kernel 5.8 always applies NX (No eXecute) anyway" so no problem on the reject.
The sharedfolder patch, I didn't use it but I suppose it's for guest extensions? Included it if you do want to try patching guest extensions, but I didn't try it. I'm guessing it's possible to run 6.1.x guest additions if I need to run a 5.8+ VM (running non-matching guest additions is likely not supported, but neither is vb 6.0.x series anyway, if it works it works, if not try the patch I suppose.)
comment:57 by , 4 years ago
Still doesn't run... SUP_IOCTL_LDR_OPEN failed (VERR_NO_EXEC_MEMORY). Will look into it.
comment:58 by , 4 years ago
Sorry, looks like patching up 6.0.x will be more difficult. Those patches above compile, and I found several more patches from the 5.8 meta-oe-vboxguestdrivers-Fix-buil-with-kernel-5.8.patch I had missed that applied and built cleanly, but no dice. I ended up with "Failed to load R0 module /usr/lib/virtualbox/VMMR0.r0: RTLdrGetBits failed (VERR_SYMBOL_VALUE_TOO_BIG).", due to not applying more needed patches that will not apply cleanly.
The first few patches are the "the system call got renamed, or moved to another header" type of patches, a 1 line fix; the map_vm_area() changes look more extensive but contained, and patch code that's identical in 6.0.24 to 6.1.14 or whatever they were for... however, the map_vm_area() replacement relies on the ELF loader patches that are in the meta-oe patch (ring 0 binary it loads is an ELF executable), but THOSE patches don't apply cleanly at all, even patching files that don't exist in 6.0.24. Probably doable but a bit more time than I care to spend working through it... my single 64-bit system that does not have virtualization extensions is not fast at all, and runs a VM even slower, I just thought I'd put up some quick patches if I could.
Text string: get_vm_area
trunk/src/VBox/Runtime/r0drv/linux/alloc-r0drv-linux.c
get_vm_area() has been removed from the 5.8 kernel tree with:
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20200408115926.1467567-8-hch@lst.de/
https://www.spinics.net/lists/arm-kernel/msg797407.html
Solution: replace with:
http://linuxppc.10917.n7.nabble.com/decruft-the-vmalloc-API-td172511.html#none
https://lkml.org/lkml/2020/4/8/298
10/28 mm: only allow page table mappings for built-in zsmalloc
This allows to unexport map_vm_area and unmap_kernel_range, which are
rather deep internal and should not be available to modules. https://patchwork.ozlabs.org/project/netdev/patch/20200408115926.1467567-11-hch@lst.de/
http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/sanitize-vmalloc-api
Text string: map_vm_area
trunk/src/VBox/Runtime/r0drv/linux/alloc-r0drv-linux.c
Could not find the text string: unmap_kernel_range
cpu_tlbstate:
hidden with:
Subject: [patch 00/15] x86/tlb: Unexport per-CPU tlbstate
Date: Sun, 19 Apr 2020 22:31:37 +0200
https://lore.kernel.org/lkml/20200419203137.214111265@linutronix.de/
[https://lore.kernel.org /lkml/20200419203336.226245149@…/]
Subject: [patch 02/15] x86/cpu: Uninline CR4 accessors
https://lore.kernel.org/lkml/20200419203335.856333226@linutronix.de/
Apparently we've also had a change affecting: trunk/src/VBox/Additions/linux/sharedfolders/vfsmod.c
starting with 5.8-rc1 vermagic.h cannot be included anymore: https://elixir.bootlin.com/linux/v5.8-rc1/source/include/linux/vermagic.h
but we don't need it anyways in that file.