Hacker News Reader

Comment by krschultz | Hacker News Reader

It isn't hard to do, but a painless way to learn is to install a ubuntu 10.10 instance in a virtualbox and try it all in the box. If you screw up, who cares. After you have been through the process once it won't be intimidating to do it for your real OS.

View on HN

Yes, it's indeed quite easy to compile your own kernel, and virtualbox is a good idea. (For compiling you won't actually need the virtualbox, but for booting from it without worries that you broke something, virtualbox sure comes in handy.)

I use "sudo make menuconfig", which gives you a text-based menu, there may also be a graphical version. I would not recommend "sudo make config", as that only gives you a long list of questions to answer.

Anyway, the trick is to read all the documention, and stick with safe choices, if you do not know what you are doing.

  # sudo make xconfig

should give you a point-and-click interface to the same menu. I haven't used it in years, but it was pretty clunky back then. It's just nicer to poke around in than the text-mode menu.

You don't need to be root to compile a Tk application and run it! You also don't need to be root to compile the kernel.

You only need root to copy vmlinux to /boot and copy the modules to /lib.

You should probably start with the .config from your distribution's kernel, rather than the stock vanilla kernel .config. It's usually in /boot, so in make menuconfig/make xconfig you choose to load an existing saved config, then select /boot/config-[kernel version] (assuming your distribution installs the kernel config there). Some kernels may also provide the .config contents in /proc/kconfig (or something similar -- can't remember the exact filename).

One thing to consider in terms of building a new kernel is that repos tend to customize their release kernels quite a bit, by adding non-mainline patches, extra drivers, etc.

Recompiling a vanilla kernel (from the linux-next git) is a pretty easy process, but you may find that when running it you've lost some nice features of the release you run or odd things have stopped working.

One might get better results from using a vendor supplied release kernel source tree (installing the kernel sources package for the repo) and then applying a patch to add the new scheduling groups. Making a patch like that is probably too hard for a newbie, but I'd be surprised if someone on the ubuntu forums doesn't end up providing one sometime soon.

in ubuntu, the config used to compile the kernel is available at /boot/config-`uname -r`

copy it to the source dir and name it as .config

yup, but that gets you a clone of the configuration options - which is important - but doesn't include the source patches, reverts, backports etc. that ubuntu made to their release kernel. I haven't looked at 10.10 specifically, but there are likely a fair number of them - many vendors customize extensively and few (if any?) ship 100% vanilla.

It's often not a problem to replace a release kernel with a vanilla kernel, but it can definitely change some behaviors or bite you if you're a special case or are using drivers not in the kernel tree.

Should I be pulling in the source from apt and applying the patch that way? I am forced to use nvidia's drivers, and I fear the vanilla kernel may not work.

Don't be too afraid. Nvidia's driver come as a module. There's lots of documention out there, how to make them work.

How do you stay up to date with Ubuntu's changes?

Ubuntu's changes to the kernel usually just backport new kernel features/fixes to an older kernel version. Compiling a fresh mainline kernel will get you most or all of those fixes. The source code shim that loads Nvidia's blob can be automatically recompiled by dkms when you boot into the new kernel. Installing the nvidia-kernel-dkms (or similarly-named) package should make that happen.

Reply on news.ycombinator.com