I want to compile and install a kernel.org kernel on a custom HDD volume, say /dev/sda5, instead of being merged with my current Ubuntu's directories.

I can find information about configuration and compilation process all over the web, but there's no track of how to put the kernel on a custom volume (different than the booted distro you're using at the moment of compile). What I'm asking for is like how we can install 2 different distros on 2 different volumes on 1 HDD, now think of my custom kernel as another distro.

  • I don't understand the question. It's trivial to copy a kernel file wherever you like. What do you hope to do with this kernel? – Gilles Jan 12 '12 at 1:12
  • You mean I can extract the source inside my desired volume (here /dev/sda5) and compile it there, and directories will be put there? I mean if I do so, won't boot directory , for instance, be copied into my current booted Ubuntu's /boot? What I'm intending to do is like compiling a software with --directory-prefix=/opt/foobar/, so all the files are put in the desired location. You know what I mean? – Haix64 Jan 12 '12 at 11:22
  • No, I don't know what you mean. You can extract the source and compile the kernel wherever you like. What do you intend to do with the kernel? – Gilles Jan 12 '12 at 11:43
  • To install multiple distributions on the same disk, simply partition your disk, install all the distributions, boot into Ubuntu, say sudo update-grub, and it'll detect all the distributions and add GRUB menu entries for them. It really would help lots if you could explain your intentions at a high level, though. I.e. are you rescuing a system, bootstrapping a Linux installation, making your own distribution, compiling a kernel for a slower computer, cross-developing, or what? – Alexios Jan 12 '12 at 15:46
  • thanks for all your comments, there's a lot of new things I know now. – Haix64 Jan 12 '12 at 20:42

You can compile a kernel anywhere you like, including your home directory. The only time directories outside the build tree are modified is when you make one of the install* targets. So, to install a kernel you'd do the obvious:

tar -xjvf linux-$VERSION.tar.bz2
cd linux-$VERSION
make mrproper menuconfig
# Configure the kernel here.
# Now build it using all your CPU threads in parallel.
make -j$(grep -c processor /proc/cpuinfo) bzImage modules

After you configure the kernel, it'll be built. At this point, you'll have a kernel binary (vmlinux) and a bootable kernel image under arch/$YOUR_ARCHITECTURE/boot/bzImage.

If you're building a monolithic kernel, you're done. Copy the uncompressed file (vmlinux) or compressed file (bzImage) to your intended volume, configure the boot manager if you need to, and off you go.

If you need to install modules, and assuming you've mounted your target volume on /mnt, you could say:

INSTALL_PATH=/mnt/boot \
make modules_install

This will copy the kernel image to /mnt/boot and the modules to /mnt/lib/modules/$VERSION.

Please note, I'm oversimplifying this. If you need help building the kernel manually, you should read some of the documents in the kernel source tree's Documentation/ subdirectory. The README file also tells you how to build and install it in detail.

Booting the kernel is a different story, though. Most modern distributions use a initial RAMdisk image which contains a ton of drivers for the hardware needed to bring up the rest of the kernel (block devices, filesystems, networking, etc). This process won't make this image. Depending on what you need to do (what do you need to do?), you can use an existing one or make a new one using your distribution's toolchain. You should check the documentation on update-initramfs.

There are other issues too, though. Using the standard toolchain you can't compile a kernel for a different architecture or sub-architecture. Note that in some cases, even kernels compiled on a particular type of x86 box won't work on certain other types of x86 boxes. It all depends on the combination of sub-architectures and the kernel config. Compiling across architectures (e.g. building an ARM kernel on an x86 machine) is altogether out of the question unless you install an appropriate cross-compilation toolchain.

If you're trying to rescue another installation or computer, however, a rescue disk might come in handier than building a custom kernel like that.

One more thing: if you're trying to build a kernel for another computer which boots, is the same architecture as the one you're compiling on, and runs a Debian or Debian-like OS (Ubuntu counts), you could install the kernel-package package (sudo aptitude install kernel-package). Then unpack the kernel, cd to the root of the source tree, and say:

CONCURRENCY_LEVEL=$(grep -c processor /proc/cpuinfo) \
sudo make-kpkg --initrd binary-arch

This will apply necessary patches, configure the kernel, build it and package it as a .deb package (a few packages, actually). All you need to do is install it on your target system and you're done.

  • Man! Thanks for your answer, and all the time you put to write it, I'm jazzed :-D. Well, I'll now try compiling the kernel, and then study in detail all you've said above. 2 things I've gotta say: First, I'm not that amateur to not grasp the above material even in more complex form, but thanks so much for your clear explanation, and second, what I intent to do with the kernel is to just mess around with it, manipulate it ... do whatever is possible, with it, because I wanna learn it all. And the outcome I'm after is this on my /dev/sda5/: /boot, /bin, ... Thanks so much! – Haix64 Jan 12 '12 at 20:45
  • That's it man! INSTALL_PATH is exactly what I was looking for, and to be honest, the first time I read through your answer I did't notice it :-D ! It's about 30 mins past my compile process. I'll do whatever it takes and will figure out everything about kernel compilation process. Thank so much Alexios! – Haix64 Jan 12 '12 at 21:26
  • You're welcome — hope I wasn't patronising! For experimentation/development, you might want to set up a sandbox of sorts. With some sort of virtualisation, this whole question is moot! You have a ‘proper’ filesystem on the sandboxed installation, and you install the kernel as you always do. Or perhaps you don't: my personal preference is to just build the kernel, then boot it using qemu. QEmu can start up VM (or emulated machine) using a kernel/initrd pair it reads off the hypervisor's disk. Much faster than rebooting your physical box or a VM. – Alexios Jan 12 '12 at 21:26
  • You should be right. And to be straightforward, I just wanna study the kernel and learn about it, that's all, to learn! I'll go study about every single word in these comments and your answer that I don't know about, here's a big bunch of new information! Thanks so much again ;-) – Haix64 Jan 12 '12 at 22:31

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.