3

Please read the full question before attempting to answer, this is a bit oddball of a situation.

I support a lot of server hardware test functionality, and essentially end up managing several internal Linux distributions, supporting various kernels (and, in a bit, CPU architectures as well). These servers are PXE/iPXE-booted from minimal test images (to save on server load and boot time) that would double in size if I were to include the make tools and gcc on them.

The trick is this. Prior to boot, I don't know what will be in any given system, which means that I need to download and install kernel modules on the fly once the system has booted. These kernel modules obviously need to be a) pre-built, and b) match the running kernel. (We expect to have dozens.)

My question is this: What's the appropriate way to manage these kernel modules? I essentially need to specify a kernel the same way I specify an architecture, but to my knowledge yum (on Centos 7) has no way to say "I need a package built for X kernel." I'm less familiar with apt-get (Ubuntu), but I don't believe it has a way to do that either. Is there a way out of essentially building a parallel package management system for this? (This is essentially managing a meta-distribution...)

Improve this question
4
  • Would it really matter if the PXE boot image doubled in size? Commented Jan 20, 2016 at 18:16
  • Yes, as I'm PXE booting dozens of systems (scaling up to hundreds and thousands shortly) dozens of times. The load will eventually be split among a bank of servers, but it's a massive consideration. Commented Jan 20, 2016 at 22:03
  • I would leave a point here about Dynamic Kernel Module Support (DKMS) . It may be not useful for your case when dealing only with pre-built modules. But more easy for other users able to release module source (or partial source with blob/firmware) Commented Jan 29, 2016 at 12:59
  • Definitely a good idea. I had looked at it, and it wasn't useful for my use case due to not having build tools on my images, but it could definitely help others who find this page. :) Commented Feb 1, 2016 at 22:54

1 Answer 1

Reset to default
3

Speaking about Debian-derived distributions:

  1. They can differentiate multiple architectures within the same repository (including 32bit vs 64bit).
  2. The kernel modules are stored in a kernel-specific tree /lib/modules/$(uname -r)/ so you could build a package that included a module for all your possible different kernel versions and the right one would be used.

Is this sufficient as a starting point?

Improve this answer
1
  • 1
    Hmm. I'm aware of the first, but hadn't considered the second. An RPM that just blanket covers all available kernels means I'll have a larger RPM, but kernel modules don't tend to be that large. I think that's actually a reasonable solution! Commented Jan 20, 2016 at 22:06

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.