Hide Forgot
VirtualBox kernel modules are distributed under the GPL v2.0 which means RedHat/Fedora is allowed to compile them and include them. Currently these modules are not included so whenever your PC runs in secure UEFI mode and you try to modprobe any self compiled kernel module, including the ones required to run VirtualBox, you get this error: modprobe: ERROR: could not insert 'vboxdrv': Required key not available Please, consider creating a binary package which contains signed VirtualBox modules.
Fedora does not provide or support out of tree kernel modules. Your note on license is correct, however there is no intention from the Virtualbox developers to ever upstream those drivers. Fedora will not carry them.
Of course, there's a known workaround http://gorka.eguileor.com/vbox-vmware-in-secureboot-linux/ however it's way too complicated for 99.99% users out there. (In reply to Josh Boyer from comment #1) > However there is no intention from the Virtualbox developers to ever upstream those drivers. Fedora will not carry them. I wonder since when sources under the proper license are not enough. We're not talking about including NVIDIA/AMD blobs, or adding new firmware files (which Fedora is not averse to at all). I do understand that Oracle now competes with Redhat (so it might be a motivation for such a refusal) and it has open disputes in regard to Android, but that doesn't mean that Fedora users have to _suffer_. You neither infringe on any patents, nor break the terms of any licenses by including VirtualBox modules. In fact other distros (Debian based ones) have long included precompiled VirtualBox modules, so if Fedora is actively seeking to reduce its dwindling user base, then I wholeheartedly agree with your decision. Perhaps I will too leave Fedora after being its user for almost 20 years (I started with RedHat Linux) since I don't care in the slightest about "no intention from the Virtualbox developers to ever upstream those drivers". The Linux kernel contains literally hundreds of half baked drivers, yet mostly stable VirtualBox drivers are actively avoided.
(In reply to Artem S. Tashkinov from comment #2) > Of course, there's a known workaround > http://gorka.eguileor.com/vbox-vmware-in-secureboot-linux/ however it's way > too complicated for 99.99% users out there. > > (In reply to Josh Boyer from comment #1) > > > However there is no intention from the Virtualbox developers to ever upstream those drivers. Fedora will not carry them. > > I wonder since when sources under the proper license are not enough. We're > not talking about including NVIDIA/AMD blobs, or adding new firmware files > (which Fedora is not averse to at all). License alone does not determine whether Fedora carries anything. That is the minimum bar. Specific to the kernel, we have additional criteria that take into account time and upstream-ability. And you are correct that we carry firmware found in the upstream linux-firmware project, despite them being binary blobs. Fedora as a project has an exception for those. They are carried because devices simply don't work without them, but if the blobs are broken we cannot do anything about aside from reverting to older versions or bugging vendors for fixes. It is not an ideal situation, but it is the only practical choice we have. > I do understand that Oracle now competes with Redhat (so it might be a > motivation for such a refusal) and it has open disputes in regard to > Android, but that doesn't mean that Fedora users have to _suffer_. This has nothing to do with Oracle or Red Hat or Android. > You neither infringe on any patents, nor break the terms of any licenses by > including VirtualBox modules. In fact other distros (Debian based ones) have > long included precompiled VirtualBox modules, so if Fedora is actively > seeking to reduce its dwindling user base, then I wholeheartedly agree with > your decision. > > Perhaps I will too leave Fedora after being its user for almost 20 years (I > started with RedHat Linux) since I don't care in the slightest about "no > intention from the Virtualbox developers to ever upstream those drivers". That would be unfortunate. I can understand your point of view as a user, however that does not change the fact that maintaining those drivers would be an additional burden. Fedora offers a standard virtualization option of KVM, usable either with Gnome Boxes or VirtManager. We also build the upstreamed VMWare and HyperV drivers. > The Linux kernel contains literally hundreds of half baked drivers, yet > mostly stable VirtualBox drivers are actively avoided. Your experience with VirtualBox drivers runs counter to ours. They break at least once per stable kernel release often causing people's machines not to boot. Fixing them would incur additional burden on the kernel team, which we do not have time for particularly when the development team behind them chooses to not leverage the benefits pushing them upstream would bring. The last time we discussed this with that team, they did not want to set a stable kernel/userspace API/ABI. That means the combinatorics of userspace VirtualBox + vbox drivers + kernel grows quite a bit. The drivers can be (and I think are?) packaged elsewhere for Fedora. Thank you for your request. I hope you remain a Fedora user.
(In reply to Josh Boyer from comment #3) Thank you for your kind response! Let's consider a few things: 1) There are more than many people willing to maintain said modules - I for one can do that, so there's very little burden for your maintenance team other then, hit "Confirm". 2) Out of all your users less than 5% use VirtualBox and since they know what VirtualBox is and how to install and run it from externals sources, then those users are more than capable of understanding that Fedora cannot be held responsible for whatever crashes might occur in a process. 3) Writing an extra tiny patch for the Linux kernel which makes the kernel tainted whenever the user tries to start any of Virtual box modules is trivial and it will protect you from whatever bug reports user might want to file. This is a bit dishonest but I don't think anyone will object. And, as far as I remember, your policy is to dismiss any bug reports where the tainted kernel is implicated. Considering the above three points I see no harm in including potentially devastating VirtualBox modules. Perhaps, the best way to discuss this proposal is to bring it to the attention of FESCo once again and if you can and are willing to do that, I'll be forever grateful. There's a word in the street that RedHat needs more users to test Fedora in order to solidify RHEL and a move like this will surely be very beneficial for RedHat itself and the popularity of Fedora.
(In reply to Artem S. Tashkinov from comment #4) > (In reply to Josh Boyer from comment #3) > > Thank you for your kind response! > > Let's consider a few things: > > 1) There are more than many people willing to maintain said modules - I for > one can do that, so there's very little burden for your maintenance team > other then, hit "Confirm". I don't follow what you mean by hit "Confirm". While I don't want to assume anything either, I don't believe you are taking rawhide into account. We update the kernel significantly faster there. It is also unclear to me whether you mean carry them as separate kmod packages, or as patches in the kernel SRPM. Separate kmod packages don't address the issue you reported, as they would not be signed with the appropriate key (they cannot be as we do not save the module signing key from kernel builds). They're also rather finicky from an end user standpoint. Carrying them as patches in the SRPM means continually fixing the patches. > 2) Out of all your users less than 5% use VirtualBox and since they know > what VirtualBox is and how to install and run it from externals sources, > then those users are more than capable of understanding that Fedora cannot > be held responsible for whatever crashes might occur in a process. Yet our experience with them shows exactly the opposite. They download virtualbox, then when it breaks on a kernel update they file reports saying it is the kernel's fault. > 3) Writing an extra tiny patch for the Linux kernel which makes the kernel > tainted whenever the user tries to start any of Virtual box modules is > trivial and it will protect you from whatever bug reports user might want to > file. This is a bit dishonest but I don't think anyone will object. And, as > far as I remember, your policy is to dismiss any bug reports where the > tainted kernel is implicated. We already had such a patch for quite a while. It wasn't needed any longer as the kernel build system now automatically taints O when out-of-tree modules are loaded. That does not prevent users from manually filing bugs. And while we do tend to close tainted bugs out, we at least try and ask them to recreate without the modules loaded first and then only close it if that is not possible. All of that leads to more bugs and more time spent. > Considering the above three points I see no harm in including potentially > devastating VirtualBox modules. Nobody said the modules were devastating. Let's avoid hyperbole. While I appreciate your optimism that there is no harm, none of the three points actually changes anything we have actually experienced. > Perhaps, the best way to discuss this proposal is to bring it to the > attention of FESCo once again and if you can and are willing to do that, > I'll be forever grateful. I'm sorry but I'm not personally supportive of that.