1

I recently had to do a custom build of the Linux kernel from its source. That custom kernel is now installed on the machine I used to build it and works fine.

Now there are other similar systems (i.e. hardware wise) in which I'd like them to run the same kernel. I don't particularly want to rebuild the kernel again on each one of them, AFAIK if the hardware is similar from one machine to another, there shouldn't be a need to rebuild the kernel.

If that assumption holds, what would be the most efficient way to deploy the existing kernel build onto similar machines?

A couple of options come to mind:

  1. copying over the custom build files from /boot/ and /lib/modules/
  2. generate an rpm with the custom kernel, in order to easily deploy it whilst keeping track of all the installed files (and thus, easy to remove too)

Other options? As anyone got experience with this?

1

I'm not sure how similar your machines are, but I've worked on deploying the Kernel to many identical systems. Option 1 is typically how I'd do this - just pushing the new kernel and modules out over the network. Though if you have a package manager on the system, an rpm package wouldn't be a bad way to do it either.

If there are some hardware differences in the system, there's a chance the kernel would have issues. Like if there's a different Ethernet MAC on one machine, you may need to enable support for that specific hardware.

Basically, you could enable everything the kernel has to offer to get a bloated kernel with support for every system, or you can find out precisely what hardware you're working with and enable support for only that hardware - producing a slimmer kernel.

1

Assuming that all the systems are running the same distribution, generate an RPM (assuming that's the package format your distribution uses) and deploy that. This has multiple benefits and basically no downside.

  • Generating a package following your distribution's procedure ensures that everything will be in place — not just the kernel but the initramfs (if used), the modules, the bootloader update scripts, the documentation, the debugging and module build information, etc.
  • Generating a package gives you version tracking. Even if a machine was down or had a disk full when you deployed an upgrade, you can find out what is installed now.
  • Using the package manager, you can deploy any software, not just a kernel. You don't need to reinvent the wheel for each software you want to deploy.
  • If your distribution doesn't have a documented way to make your own kernel packages, then there's an upfront cost. But if it does, and I think most do, then the upfront cost isn't larger than gathering all the necessary bits manually.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.