#119 Add minimal -devel packages as needed to build kernel modules
Merged 2 years ago by walters. Opened 2 years ago by alexl.
alexl/workstation-ostree-config kernel-build-headers  into  master

file modified
+6
@@ -14,6 +14,12 @@ 

    # hfs filesystem tools for Apple hardware

    # See https://github.com/projectatomic/rpm-ostree/issues/1380

    - hfsplus-tools

+   # Bundle the minimal -devel packages needed to build a kernel.

+   # This is needed because we can't rely on layering to install these

+   # due to version conflicts with the base image.

+   - glibc-devel

+   - kernel-devel

+   - elfutils-libelf-devel

  

  repos:

    - fedora-rawhide

As discussed in the forum[1], package layering can work for building kernel
modules, such as the nvidia driver. However, there are some problems
with the -devel packages needed, as they need to match the exact version
in the base image, and once the version bumps in the yum repo the old
version isn't even available.

So, this adds the minimal set of -devel packages needed to build a a kmod.
This isn't enough to build a kernel module, but the rest needed can much
more easily be layered.

Given the current rawhide dependencies this adds the following packages:

  • elfutils-libelf-devel
  • glibc-devel
  • glibc-headers
  • kernel-devel
  • kernel-headers
  • libxcrypt-devel
  • zlib-devel

This adds about 100 megs to a 4 gigabyte image, which I think is a fair
compromise in order to be able to build kernel modules and support
the nvidia drivers.

[1] https://discussion.fedoraproject.org/t/supporting-the-nvidia-drivers-on-silverblue/849/6

should we just get with the rpmfusion guys and come up with a build system that will build a popular set of kernel modules (nvidia included) for every kernel that comes out?

Actually having pre-built nvidia drivers for fedora kernels at time of the release would be great. But, that is a political question of larger scope than just making the existing akmods setup work with silverblue.

Actually having pre-built nvidia drivers for fedora kernels at time of the release would be great. But, that is a political question of larger scope than just making the existing akmods setup work with silverblue.

Agree. I was just wondering if anyone had explored that option before.

Don't we need gcc too at least? I know this is solving a real-world problem but...having development tools on the host - particularly by default - is pretty directly against the idea behind Silverblue.

And I think it'd be even more against the Fedora CoreOS philosophy. Which is part of the idea with all of this; tooling and models we develop for FCOS should flow into Silverblue. (Now of course in this case it's work for Silverblue that might apply to FCOS)

Now maybe we could develop an approach to move it to /usr/lib/kmods/gcc or so? Would get...tricky though if we still wanted to support rpm-ostree install gcc. I guess we'd really need to change the rpmdb entry too.

We could have a hybrid solution where we still build in a container, but include the headers on the host so they can get bind-mounted into the container.

@walters No, the point is not to add everything needed to the base, but just the things that are hard to layer. gcc for instance should be perfectly fine to layer as it never conflict with anything in the base. Of course, once you actually layer an akmod rpm that will pull in gcc, make and rpm-build.

and once the version bumps in the yum repo the old version isn't even available.

It's more accurate to say it's "less convenient to access" (admittedly by a fair amount). But one can definitely find the packages both in the compose directory as well as koji of course. Addressing the "rpm-md history" issue in a more rigorous way would help a lot more problems than just this. (It's actually crazy how many times this has been talked about but no action taken)

gcc for instance should be perfectly fine to layer as it never conflict with anything in the base

Ah, I see. Hmm. One thing I noticed on this topic is that the "pocl" package which something else is pulling in already grabs some of these headers anyways which seems like a bug.

So...I'm not strongly opposed to this PR as is, but...besides the rpm-md history angle, we could post a script like "rpm-ostree-akmods-prep" that people can run that layers those packages? Or include such a script with the akmods package. The main downside of this is that more people would hit the split/versionlocked issue but we want to solve that anyways, and further it's not obvious to me that your assertion that the other layered packages in the gcc depchain wouldn't come with their own split/versionlocks.

Obviously there is no guarantee that the other build dependencies don't run into some version lock issue. But, its much less likely that this would happen, instead of as now where it is virtually guaranteed.

Also, I don't think there is anything fundamental with this PR. Its mainly a practical solution to a quite important problem (nvidia support). If we eventually fix https://github.com/projectatomic/rpm-ostree/issues/415 then we can revert it.

So, any chance we could merge this? Then i could continue with the various other fixes needed for nvidia support.

OK, since this doesn't include gcc by default that addresses my main concern about the host being a development environment by default.

Pull-Request has been merged by walters

2 years ago
Metadata