Bug 9467

Summary:	[FEATURE REQUEST rosa2019+] Provide the external kernel modules as binaries by default
Product:	[ROSA-based products] ROSA Fresh	Reporter:	Evgenii Shatokhin <eugene.shatokhin>
Component:	Packages from Main	Assignee:	ROSA Linux Bugs <bugs>
Status:	CONFIRMED ---	QA Contact:	ROSA Linux Bugs <bugs>
Severity:	major
Priority:	Normal	CC:	andrey.bondrov, eugene.shatokhin, v.potapov
Version:	All
Target Milestone:	---
Hardware:	All
OS:	Linux
Whiteboard:
Platform:	---	ROSA Vulnerability identifier:
RPM Package:		ISO-related:
Bad POT generating:		Upstream:

Description Evgenii Shatokhin 2018-10-30 06:10:17 MSK

This is a feature request for the new ROSA platform (2019.1 or whatever it will be called).

Currently, ROSA R11 provides the external kernels modules (the ones not included into the kernel RPMs) as dkms packages. The common examples are dkms-virtualbox, dkms-broadcom-wl, dkms-nvidiaXYZ and such. This turned out to be inconvenient and error-prone. The modules are rebuilt at the user's system each time a new kernel is installed or at boot time, which may take a while and cause other problems. See https://bugzilla.rosalinux.ru/show_bug.cgi?id=9463, for example.

I suggest to provide such kernel modules as binaries by default (but keep dkms packages in the repositories as well, in case the users built their custom kernels). This is what MS Windows and many Linux distros (Ubuntu, Fedora, OpenSUSE, ...) have been doing for ages.

This would make it easier for the users to install the proprietary video or WiFi drivers. It would also make the drivers more reliable. For example, we'll catch the build errors in the drivers at package build time rather than have the user go through the usual "I have installed the NVidia drivers, there were some error messages, I have rebooted the system and now I have no graphics, please help!"

I think, providing the binaries for the kernel modules from "main", "non-free" and "restricted" repositories would do as a first stage. As for "contrib" - this can be decided later.

By the way, building the modules at ABF rather than at the users' side will also be convenient if it is needed to sign the modules with ROSA keys and disallow unsigned modules. Can be of interest if there is a flavour fo ROSA in the future, designed for better security.

Comment 1 Evgenii Shatokhin 2018-10-30 06:33:14 MSK

A tentative list of requirements:

1. 
1.1. Each kernel build at ABF triggers the builds of the packages with driver binaries for a given list of drivers. The errors are reported to the maintainer as usual.

1.2. Ideally, both the kernels from import group at ABF and the custom kernels (e.g. from kernels_stable_personal repos, etc.) should be supported here.

1.3. The maintainer should be able to switch off the automatic builds of the binary driver packages for debugging or testing purposes (e.g. when it is known in advance that a particular driver won't build for the given kernel).

2. dkms-packages for the drivers remain available in the repositories, they are rather not installed by default.

3. The source code of the drivers is kept in separate projects at ABF (like it is now) rather than included into the kernel packages. This is needed because of licensing issues and because we need to be able to update the driver packages separately from the kernel.

4. Changes to the kernel project files as well as the driver projects needed to support this are kept to a minimum.

No hardcoded list of drivers to rebuild, etc.

This is a requirement because there are many kernel packages at ABF (at least one per branch like 4.9.x, 4.15.0-x, etc.) - if massive changes were required in these project, that would be hard to maintain.

5. A driver package can be updated separately from the kernel too. For example, when a new version of the driver is released upstream or some fix has been added, etc.

In this case, the maintainer of the driver updates the dkms-package for the driver and the driver binaries should be build automatically for all kernels available in the given list if repositories (again, not hard-coded in the driver or kernel projects). rpm macros or smth like that could do, I guess.

6. When a user has some packages with the binary drivers installed and then updates the kernel, the updates for these binary drivers are also installed.

7. Not all the drivers built as binaries are installed by default. For example, NVidia graphics drivers and VirtualBox guest additions are known to cause problems when installed on the systems without the respective real or virtual hardware.

Comment 2 Evgenii Shatokhin 2018-10-30 06:36:43 MSK

First of all, it may be helpful to investigate the solutions for this problem that other major Linux distros use: Ubuntu, Fedora, OpenSUSE, ...