Copying a Linux Kernel From One System to Another

There may be occasions where, for testing purposes, you want to copy a kernel from one machine to another.

There are some fairly self-explanatory caveats:

  • The donor and target system must be running on the same architecture
  • The target machine shouldn't have any (important) hardware that's unsupported by your donor kernel

Obviously, you'll ideally want to make sure that the hardware is as close to identical as possible (otherwise your testing may be invalid) so the above should be considered a minimum



  • /boot is part of the root partition - If you use a seperate partition for /boot, you'll need to mount it.
  • Your grub config is at /boot/grub/menu.lst, if it's elsewhere, substitute the path
  • You're comfortable with editing grub's config - if you render your system unbootable it's your issue to sort out :)
  • If you're working on a remote server, you've got the sense to ensure you've got out of band access


Procedure (Donor machine)

There are essentially three things we need to grab a copy of;

  • Compressed Kernel
  • The initrd/initramfs image
  • The kernel modules for our version

So, SSH onto the Donor machine and do the following

uname -a
# We'll assume the response gave us a kernel version of 2.6.32
# Boot requisites first
ls /boot # Check the filenames
mkdir -p kernelexport/boot
cd kernelexport/boot
cp -p /boot/vmlinuz-2.6.32 ./
cp -p /boot/initramfs-2.6.32.img
cp -p /boot/grub/menu.lst ../

# Modules Next
mkdir ../modules
cd ../modules
cp -rp /lib/modules/2.6.32 ./
cd ../..
tar czf kernelexport.tar.gz kernelexport/

You now need to get that tarball onto the target system


Procedure (Target System)

We've now brought the basic requirements for our kernel over, so we just need to configure the target system to actually use is

tar xvzf kernelexport.tar.gz
cp -rp kernelexport/modules/* /lib/modules
cp -p kernelexport/boot/* /boot/

The next stage is our first opportunity to make a serious mistake - we need to configure grub to use our new kernel, based on the configuration on the Donor system (which is why we pulled menu.lst down).

Read our downloaded menu.lst and find the section relevant to the kernel we want to boot

less kernelexport/menu.lst

We're initially going to copy that section into the live grub config, so

nano /boot/grub/menu.lst

Paste in the section we've taken from the Donor machine's config - this is where careful attention needs to be paid. On some systems, the path to an initrd may start with /boot on others it may simply start with a / (the same is true of the kernel path).

Compare the new entry to existing ones

Once you're happy, set Grub's timeout high enough that you'll be able to select the new kernel

Check that permissions in /boot match those of the existing files

ls -l /boot




Possible Failures

Error 15: File not Found

If grub returns this error, odds are you weren't careful enough when editing grub's config and have defined the path to either the kernel or the initrd incorrectly.

Reboot the system and choose the original kernel in Grub so that you can rectify the error.


You have hardware that's used early in boot, but didn't exist on the donor

You shouldn't find yourself in this position, and if you do, consider whether the following will invalidate your testing (if you're using different hardware, you're almost certainly following different code paths).

If the system won't boot, you may need to rebuild the initrd/initramfs image. So reboot into the old kernel and do the following (change the filename to match your situation)

cd /boot
mv initramfs-2.6.32.img initramfs-2.6.32-504.16.2.el6.x86_64.img.old
dracut -f initramfs-2.6.32.img 2.6.32

Once it reports success, reboot and hopefully the system will come up



It's not that often you'll find yourself in the position of needing to move a kernel in this way (for most issues/tests installing from the same RPM/DEB or compiling with the same config would probably be enough).

On the rare occasion that a need does arise though, it's very straightforward to do, and as long as the underlying hardware is sufficiently similar the only real headaches likely to arise are the result of human error

One final thing to consider is whether you also want to pull the source tree across - whether it's needed will obviously depend on whether you intend to do anything which may require access to the source.