If you’ve ever tried compile a linux kernel yourself you know the headache of configuring and taking care of dependencies. KernelCheck makes this a point and click process for debian based linux distributions such as Ubuntu. You can use it to compile and install any 2.6.* stable kernel as well as the bleeding edge. KernelCheck even offers custom compilation options such as including kernel patches or rolling in proprietary video drivers. A tutorial (PDF) is also provided so you can see what you’re getting yourself into.
[via Web Upd8]
What dependencies ?
I’ve never had any problem with dependencies on a kernel compile. o.O The only issues I have is with binary drivers that crap themselves and take the kernel with them.
However, I suppose it might be handy for folks relatively new to linux who want to start rolling their own kernel. You may also want to take a look at Genkernel [http://en.wikipedia.org/wiki/Genkernel], for something that does a similar job.
seriously, maybe i’m just jaded since i’ve been compiling my own kernels for seven years now (jesus christ, it’s been that long) but the hardest part of compilation is knowing what hardware you have and making that be supported. the actual mechanical process is just typing ‘make && make install’. if you’re going to make a kernel that has drivers for every piece of hardware and every software option enabled like this seems to, why bother rolling your own?
I mean, it’s cool to see gui software to automate things, but this just seems to be a gnome version of `make xconfig’ with the ability to pre-patch the source?
/me wonders why people feel the need to build their own kernels..
most people that build their own kernels have no reason to (they aren’t using patches like vserver) and don’t understand concepts like the initramfs and modules system which means they don’t actually need to build a kernel.
people talk about building “their own kernel” as if invoking make means they’ve written their own os.
WTF! I’ve been compiling my own kernel with ‘make menuconfig’ since the 2.2 series. there is nothing complicated about it; people are afraid to do it ’cause they think it’s a big deal. Install gentoo one time and you’ll learn all about rolling your own kernel, bootloaders and filesystems.
@cantido
There are plenty of reasons to roll your own kernel. what about if you don’t have the ram to load drivers for all sorts of hardware you don’t have or when a particular piece of hardware needs to work before you can load the drivers? I’ve run Linux on all sorts of hardware and sometimes you’ll save yourself a lot of trouble rolling your own.
Umm… where’s the problem with compiling a kernel? It’s just a matter of picking the right parts (depending on kernel version) from:
make oldconfig
make config
make menuconfig
make xconfig
make dep
make clean
make
make modules
make modules_install
make bzImage
….
;-)
Okay, maybe I don’t get it because I compiled my first kernel back in 1995 or something (Linux 1.2.something) but people who need a GUI for compiling their kernel don’t need to compile a kernel anyway…
-Darkstar
@steve
>There are plenty of reasons to roll
>your own kernel.
There are only around 3 reasons, building kernels with non-mainline or development patches, building debug kernels, and building embedded kernels.
>what about if you don’t have the
>ram to load drivers for all sorts
>of hardware you don’t have
As I said, you obviously don’t understand how the initramfs and module system work. If you don’t have a piece of hardware, a module doesn’t get loaded for it. The only reason a piece of driver code would be loaded is if it was built into the kernel, but with initramfs images barely any driver code has to be built in.
> or when a particular piece of
> hardware needs to work before
> you can load the drivers?
initramfs. The kernel also has the ability to have a ramfs built inside the kernel image, so as long as your bootloader is capable enough to load the kernel into memory there is a way to load driver code from modules. The ram fs stuff is jettisoned once the system has chroot()’ed into the real fs, so no memory is wasted on stuff you maybe don’t need.
>I’ve run Linux on all sorts of
>hardware and sometimes you’ll
>save yourself a lot of trouble
>rolling your own.
I’ll have a whip ’round and get you a medal. If use NetBSD or any other kernel without(not sure if that’s still the case) runtime module loading building kernels can make sense. With most mainstream linux distros there’s no point and only results in you getting called a moron when you come into support channels to get help to with your unbootable system.
wow, that was hostile and in informed. initramfs is not a required part of Linux and is not included in every distro. If you want to just use prebuilt modules and be happy about it then go ahead and do so but don’t insist you know the only 3 reasons to roll your own kernel. I have had at least 3 pieces of hardware for which I had to manualy edit the source for and then recompile in order to get working. I’ve run Linux on x86, amd64, ppc, ppc64, arm and mips platforms, and certain issues arise that necesitate a deviation from the norm mainstream set up. is recompiling the kernel needed for the average user on typical comodity hardware; NO! but that doesn’t mean there is only the three reasons you know about to ever do it. if you don’t apreciate the option to do things your own way then quit hating and go by a mac; they come with all the precompiled kernel extensions you could ever need.
> initramfs is not a required part of
> Linux and is not included in every distro.
I’m not sure you can compile a kernel without some ramfs code any more actually. The kernel is a lot more complicated beast than it was 3 or 4 years ago… klibc etc etc. Anyhow most distro’s use initramfs images for booting, its essential if you want to be able to boot from anything more complex than a bios partion on a harddisk, i.e. you can’t mount filesystems from a lot of RAID setups without userland tools, LVM needs userland tools really.
>If you want to just use prebuilt modules and be > happy about it then go ahead
The pre-built modules will be exactly the same as any you can build. You realise you can build modules without building the whole kernel right?
>do so but don’t insist you know the
>only 3 reasons to roll your own kernel.
No, there are only around 3 reasons for building a kernel. Unless creating pain in the arse to maintain systems is a reason.
>I have had at least 3 pieces of hardware
>for which I had to manualy edit the source
>for and then recompile in order to get working.
Modules can be built externally, you don’t need to rebuild the kernel. Building non-essential drivers, non-essential functionality (Most of the networking, disk subsystems etc can be built as modules and are built that way for the majority of distributions) into the main kernel image is moronic. Especially if you consider the fact that most BIOS/Firmware have major issues and loading big kernels into memory.
>I’ve run Linux on x86, amd64,
> ppc, ppc64, arm and mips platforms,
Ok, let’s have it out then… x86, amd64, Sparc 32bit, Sparc 64bit, m68k, PPC (look up APUS), mips, arm,.. bunch of other shit I don’t care to remember.
> and certain issues arise that
> necesitate a deviation from the
> norm mainstream set up.
Everyone that has said that in my experience hasn’t realised that you can A: build loadable modules outside of the kernel, B: most parts of the kernel are tunable at runtime via proc and sysfs interfaces, C: anything that isn’t tunable at runtime can usually be tuned via kernel command line parameters.
>is recompiling the kernel needed
>for the average user on typical comodity >hardware; NO!
99 out of 100 users, admins etc have no reason to compile a kernel, or for matter matter most of the binaries they are running.
>but that doesn’t mean there is only
>the three reasons you know about to
>ever do it. if you don’t
you’re yet to give one good reason,.. having to patch drivers isn’t a reason because you can do that outside of the kernel build. Development patches was in my list of reasons too. Development patches being something like that scsi subsystem replacement.
> apreciate the option to do things
> your own way then quit hating and
> go by a mac;
I’m writing this on a mac running linux, stock amd64 kernel, works a treat…
root@mac-chan:~# uname -a
Linux mac-chan 2.6.30-1-amd64 #1 SMP Sat Jul 18 12:55:06 UTC 2009 x86_64 GNU/Linux
>they come with all the precompiled
>kernel extensions you could ever need.
OSX is actually a microkernel, so all drivers should be userland.. it should be possible to replace most of the running system without restarting. The same should be true of any Windows NT descendant, but we all know the reality.
finally something useful on hackaday
So how is this different from make xconfig?
I don’t know what crawled up your ass but I guess you don’t need freedom of speech or the right to bear arms either huh? opensource is all about options why are you so close minded that you advocate limiting the options of others?
I did not say patching a driver, I said I rewrote several lines of code myself to get said code to compile on my machine; no patch existed at the time. Yes it is quite posible to compile the kernel without the use of initramfs and I found that this simplified bootloader settings and made for a cleaner /boot/ when I was running multiple distros. I know that kernel modules can be compiled separately from the kernel but you have to have the same kernel source and the same version of gcc to do so; which although it should be isn’t always the case. by not using an initrd and compiling only the drivers I want right into the kernel I’m able to get faster boot times and waste less disk space as I don’t have drivers I don’t need. I’m not claiming to be some Linux guru or say mine is the right way to do things, but microsofts similar close minded atitude about what people should do with hardware they own is what drew me to Linux in the first place.
>I don’t know what crawled up your ass
>but I guess you don’t need freedom of speech or >the right to bear arms either huh?
I don’t have the right to bear arms,.. not everyone lives in America.
>opensource is all about options why are
>you so close minded that you advocate
>limiting the options of others?
Well, this tool is basically going to be a frontend to make-kpkg or something that Debian/Ubuntu use.. so what’s the point? If you actually need to build a kernel you should be able to use those tools. And no, I’m not limiting the options of others, people that don’t understand stuff do silly things like build all their software and kernel according to “super fast linux howto!!!” then post stupid bug reports etc that waste developers/maintainers time. Just look at all the stupid reports on launchpad. “You must fix! I install packages off of random website! It break my computer!!!”
>I did not say patching a driver,
>I said I rewrote several lines of
>code myself to get said code to compile on my >machine; no patch existed at the time.
Well done, did you help the “opensource world(tm)” by submitting your patches upstream?
>Yes it is quite posible to compile the
>kernel without the use of initramfs
Never said it wasn’t. But without an early userland your boot options are pretty limited.
>and I found that this simplified
>bootloader settings and made for a
>cleaner /boot/ when I was running
>multiple distros.
So you saved one line per kernel in your grub/lilo config (both of which are auto generated in Debian) and one file per kernel (you can actually have your early userland inside the kernel, like I said, look up the internal cpio image stuff) but dramatically reduced your systems abilities. No rescue shell for you, no ability to move the system to a different machine and boot into it.. sounds good.
Oh, it boots about 2 seconds faster because it’s loading a small payload from disk, extracting it to ram and loading a few modules from there.. instead it’s loading the same code from disk into memory as part of your kernel image, oh wait, that’s practically the same thing just done painfully.
>I know that kernel modules can
>be compiled separately from the kernel
>but you have to have the same kernel
>source and the same version of gcc to
>do so;
This tool is for Debian + forks right.. so in Debian you have lots of lovely tools to allow you to get on with productive work,.. tools like make-kpkg, module-assistant, the build-essential meta package,kernel headers packages, kbuild packages, kernel source packages, all the versions of GCC you could need..
>by not using an initrd and compiling
>only the drivers I want right into the kernel
So you basically put your boot process in a wheel chair and then make it impossible to load “modules” with different parameters at runtime.. god forbid you actually maintain systems for a living.
>I’m able to get faster boot times
> and waste less disk space as I
>don’t have drivers I don’t need
Yes, because saving >50MB of disk space is necessary on systems with n*100GB of disk space.
>I’m not claiming to be some Linux guru
Yeah, I wouldn’t go doing that, you may look a bit silly.
>but microsofts similar close minded
>atitude about what people should do
Now you really have lost the plot. Microsoft allow almost anyone to load code into their kernel.. you know, like malware etc. Bringing Microsoft into an argument about making Linux more difficult to use and maintain out of choice is really weak. Yes, we should screw over Microsoft by throwing away the advantages that Linux has. Down with DRM!!
>with hardware they own is what drew
>me to Linux in the first place.
Hint: No commercial linux vendor will support systems running kernels you have lashed together.
“build from source, my mouse moves faster OMG!1!!”
Useful debian packages for building DEB packages from a kernel source tarball:
(1) ketchup – downloads latest kernels automagically for you and updates existing trees
(2) make-kpkg – a debian tool for building a kernel and generating an installable deb package all in one step. How to generate a kernel:
$ mkdir /home/user/kernel;
$ ketchup -d /home/user/kernel 2.6
$ cd /home/user/kernel
$ make-kpkg clean # optional
$ zcat /proc/config.gz > .config #get current config
$ make oldconfig #optional, see new options
$ make-kpkg kernel_image # parent dir holds new deb file
$ cd ..
$ sudo dpkg -i generated_kernel_deb.deb
$ update-grub # or lilo, whatever
$ sudo reboot