# Kernel binary package

## i0

Hi

Is it possible to build custom kernel binary package for distributing to other machines?

Idea is: since all machines have same hardware why should i compile kernel with same config in all machines, instead i compile in one place and just install without compilation in others.

buildpkg builds only kernel source, no binary kernel or .config.

----------

## i92guboj

Everything the kernel installs goes into /boot and /lib/modules, so tarring that should be enough.

----------

## d2_racing

Indeed, you can use that I think too, but I never tested that.

If you do, just post the result  :Razz: 

----------

## i0

In /lib/modules/ there is a folder with kernel version, in that folder there are symlinks to kernel source.

Also in case of kernel upgrade, /usr/src/linux symlink needs to be updated.

I would not like to create a archive file to be extracted in receiving machines and script to make everything right.

Is there a Gentoo way to to it?

For other binary packages i use FEATURES="buildpkg" in one machine and BINHOST definition in receiving machines.

Would like same feature for kernel.

----------

## Genone

 *i0 wrote:*   

> Is there a Gentoo way to to it?

 

No, as Gentoo doesn't manage kernel builds (well, genkernel does, but I don't think it has the feature you're looking for).

 *Quote:*   

> For other binary packages i use FEATURES="buildpkg" in one machine and BINHOST definition in receiving machines.
> 
> Would like same feature for kernel.

 

THen you'd have to write an ebuild that actually builds the kernel rather than just unpacking the sources. Or make an ebuild that simply copies the relevant files from /boot and /lib/modules, but then you could just use tar directly.

----------

## Elleni

Sorry for posting on such an old thread, but I am interested in this question too. Is there any solution to this in the meantime or is it still the same status? Does anyone already have a script/ebuild, that does the job?

----------

## eccerr0r

I think it's still the same.

That's sort of the problem with kernels, bootloaders, and especially Gentoo - since it's virtually impossible to enumerate every possibility out there.  Granted chances are it's the most common case, but what works for the common case can completely destroy a not-so-common case, so it's best not to take the risk causing an unbootable machiine.

It's better for well-cooked solutions like RHEL or SuSE or Ubuntu or something, as you know how the machine -should- be set up.  (As long as someone didn't start mucking with it outside the vendor scripts that don't always work with every hardware setup.)

----------

## szatox

Elleni, some time ago I've done some research on this topic too, and I know I wasn't the first nor the last one either.

It is possible to create ebuilds for lazy-mode kernel updates but there are some problems too.

1) Since emerge will be aware of those kernels (which is good, it would let emerge clean obsoleted modules), updating kernel may uninstall old kernel (unless you manually add it to @world). I'm not aware of a good way to make emerge keep e.g. 2 newest versions to ensure you can fall back to known working kernel should anything go wrong. Manually adding and removing every single kernel IMO defeats the point  of using ebuilds for this.

2) You can update kernel by copying previous .config and then running oldconfig. This is a good  base, but you will likely want to review those configs now and then anyway and disable some stuff you don't need. This however interferes with oh-so-handy savedconfig use flag. Yup, there is someting like that and it could be USEd by lazy updater to avoid interactive menuconfig once you've prepared one good kernel.

3) Updating grub automagically may be problematic. Emerge builds all packages in sandbox. Any write outside of your working directory will crash the build (which - again - is good). Unfortunately, bootloader's config IS outside of your working directory and you may encounter ownership conflict if you try to update it with emerge functions. Those conflicts may not even be obvious right at that time and strike you later when you don't expect that. On the other hand, the legacy way with linking vmlinuz to current kernel and vmlinuz.old to previous one is still available and could be used to workaround those limitations.

Either way, I abandoned this idea for I didn't find it worth the effort. Perhaps I'd be more inclined to make it actually usable (just _usable_, definitely not _perfect_)if I had more machines to maintain. I don't, so I gave up on attempts to make it pretty and just spent my time somewhere else.

----------

## Elleni

Hello and thanks for your replies! 

My usecase is the following. I have a friend of mine, who has almost the same Hardware, and is using gentoo which I support. For updates being easier and quicker I build binary packages for this other box, so I wanted an quick way to avoyd building the kernel there once again. I know think of rsyncing /boot and /lib/modules and doing the symlinks manually. I will try that out and see, if it works  :Smile: 

----------

