Change:
buildType = "release"; # Use maintainers/scripts/update.nix to update the version and all related hashes or # change the hashes in extpack.nix and guest-additions/default.nix as well manually. <del> version = "6.1.16"; </del> <ins> version = "6.1.18"; </ins> iasl' = iasl.overrideAttrs (old: rec { inherit (old) pname;

Discussion:
Describe the bug VirtualBox kernel modules are not able to compile with . Notify maintainers Metadata Maintainer information: /cc
Upstream bug:
Well, seriously thinking about using full QEMU + KVM. I can confirm the bug here, but from a quick read, there is still no version with this fix (test versions only), so I'm not sure of the best way here, we can add a patch for now (if the maintainers agree) or wait for the next release.
Yeah, upstream seems pretty bad in keeping up to date with kernel updates. Assuming the patches circulating in the issue tracker don't break the build in older kernels, 'ing them in nixpkgs before there's a release is fine. Can you send a PR?
I can try, will search how to first lol
Ok, after a few rounds I found what to change, reading it calmly, there seems to be 3 patches involved in the problem, one to fix the initial problem described in that issue and two to fix the DRM and shared folders in this kernel version. It's pretty late around here so I'm leaving my laptop compiling with the initial patch to test, as my biggest use of the Virtualbox is with Vagrant it is quite possible that I won't find the other two problems, but I'll investigate as well. First patch is this one: (Same as ) A PR would have to change these lines: I'm using this expression to test the patch:
People, for me, running the latest version of Zen, the first patch was all I needed, graphics ok, shared folder ok. I tested a Windows 10 previously created and two Debian 10 (via vagrant) one already provisioned and another new. Can anyone else test before sending a PR? In the meantime I will look for the possibility of using an IF for kernel versions = 5.10 and applying the patch only to them. !
Patches should be applied unconditionally (so they fail loudly when they don't apply), not only in corner cases. They of course then needs to be written to work with both kernels (but that should be the case here)
Okay, I got lost here, in theory this patch is only necessary from 5.10 onwards, so should we test it on a lower one and if everything works add it?

It can also have some other side effect, for now I'm just using via vagrant (as I usually do) and I would like someone else to test it too.
Yes, but the patch includes ifdefs, so it should work on both kernel versions. Only adding patches in some conditions is discouraged in nixpkgs. After doing version bumps, patches might not apply cleanly anymore, but it's not caught during review if only tested on a variant where the patch is "hidden by the condition". In the case of virtualbox, imagine a reviewer testing manually while on a stable kernel. They'll never realize the patch doesn't apply anymore, as it's not in the derivation they built.
First, happy new year! Second, thanks for explaining, I understand. As I am not at the computer these days, I am going to do a quick test with this patch in 5.10 Vanilla and 5.9, if everything goes well I will return with PR to merge this patch. Thank you! Future note to myself: Read the entire patch file.
Created PR
Opened , which include the latest release with fix.
Let's close this in favor of
I think the issue should remain opened until the issue is fixed in master.
Indeed - I confused this with Sorry!